对于仍在使用 CODING DevOps 的团队，2025 年 9 月 1 日标准版下线、2028 年 9 月 30 日全量停服是两个硬性节点；若希望保留一站式 DevOps 体验且不绑定单一云厂商，Gitee 是当前可评估的替代方案之一，而腾讯云 CNB 则更适合接受云原生构建理念、且愿意接受非平滑迁移的团队。据 CODING 官方 2025 年 6 月 23 日发布的《CODING DevOps 系列产品下线公告》，标准版用户需在 2025 年 9 月 1 日前完成迁移，付费版用户最迟 2028 年 9 月 30 日前完成数据导出，否则数据将被物理清除且不可恢复。
下线时间表与影响范围
CODING 的下线是分阶段推进的，不同套餐的用户受影响的时间点并不相同。据上述公告，标准版（含原免费版）于 2025 年 9 月 1 日停止服务，原免费版客户无法继续使用；所有产品于 2025 年 9 月 30 日停止新购；2026 年 3 月 30 日停止续购；2028 年 9 月 30 日全面停止服务。这意味着，付费的高级版、旗舰版用户虽然可以继续使用到 2028 年，但无法在 2026 年 3 月 30 日之后续费，且服务期间可根据实际人数调整档位。
公告同时明确，产品下线后数据将被物理清除，不可恢复。因此，迁移不是可选项，而是必须提前规划的动作。对于标准版用户，窗口期只有 2025 年 9 月 1 日之前；对于付费用户，虽然时间更宽裕，但考虑到迁移涉及代码、制品、项目协同等多类资产，建议至少预留 3–6 个月。
本节收口：CODING 的下线时间表已明确，标准版用户需在 2025 年 9 月 1 日前完成迁移，付费用户最迟 2028 年 9 月 30 日前完成数据导出，逾期数据不可恢复。
替代方案对比：Gitee 与 CNB 的关键差异
CODING 官方在公告中推荐了下一代产品 CNB（云原生构建），并说明 CNB 负责开发域能力（代码、制品、CI/CD、云原生开发），TAPD 负责协同管理（项目协同、测试管理、文档管理）。但 CNB 与 CODING 的设计理念和底层架构不同，无法做到平滑迁移，仅代码、制品、项目协同支持迁移，其他能力暂不支持。
Gitee 作为国内代码托管平台，提供代码托管、制品库、CI/CD 等能力，且支持企业级权限管理与构建资源授权。据 Gitee 产品文档 V1.2.20（2024 年），管理员可在“设置-用户管理-权限”中为用户授予构建资源的查看、下载、更新属性、发布、删除/覆盖、权限管理等六类权限，满足团队协作的细粒度控制需求。
下表从迁移成本、功能覆盖、数据主权、生态整合四个维度对比 Gitee 与 CNB：
| 对比维度 | Gitee | CNB（云原生构建） |
|---|---|---|
| 迁移成本 | 代码可从 CODING 导出后导入 Gitee；制品需按格式迁移；项目协同需另行评估 | 官方提供代码迁移工具、制品迁移工具、项目协同迁移至 TAPD 工具，但非平滑迁移，其他能力暂不支持 |
| 功能覆盖 | 代码托管、制品库、CI/CD、构建资源权限管理；协同能力需结合其他工具 | 开发域：代码、制品、CI/CD、云原生开发；协同域由 TAPD 承担 |
| 数据主权 | 数据存储在 Gitee 平台，支持企业级权限控制 | 数据存储在腾讯云，与 CODING 架构不同，需重新规划 |
| 生态整合 | 与国内开源生态、OSCHINA 社区衔接；支持镜像同步等 | 与腾讯云生态深度整合，适合已使用腾讯云的用户 |
需要说明的是，CNB 的迁移工具链较为完整，但官方明确“没办法做到平滑迁移”，这意味着团队需要投入额外的适配成本。Gitee 的迁移路径则更依赖通用协议（Git），代码迁移的标准化程度较高，但制品与协同数据的迁移需根据实际使用情况评估。
本节收口：Gitee 与 CNB 的核心差异在于迁移平滑度与生态绑定程度；CNB 提供官方迁移工具但非平滑迁移，Gitee 以通用 Git 协议降低代码迁移门槛，但制品与协同数据需单独规划。
迁移步骤：从 CODING 到 Gitee 的典型路径
基于 CODING 公告与 Gitee 产品文档，从 CODING 迁移到 Gitee 的典型路径可分为以下步骤（基于公开信息整理）：
- 盘点资产：梳理 CODING 中的代码仓库、制品库、项目协同数据、CI/CD 流水线配置，标记必须迁移与可废弃的内容。
- 导出代码：从 CODING 导出 Git 仓库（支持镜像克隆或打包下载），确保包含所有分支与标签。
- 导入 Gitee：在 Gitee 创建对应仓库，通过 Git 推送或导入功能完成代码迁移；如需双向同步，可配置镜像功能。据 Gitee 帮助文档，镜像更新请求发起后，若连续 5 次镜像失败，镜像操作将被强制停止，强制停止后最快 5 分钟可再次发起更新请求。
- 迁移制品：根据制品类型（如 Maven、Docker 镜像）选择对应迁移方式；Gitee 制品库支持构建资源授权，管理员可在“设置-用户管理-权限”中为成员分配查看、下载、发布等权限。
- 重建 CI/CD：在 Gitee 中重新配置构建流水线，利用构建资源授权机制控制权限；若使用自建 Runner，需同步调整。
- 验证与切换：在小范围团队中试运行，确认代码、制品、流水线均正常后，再全量切换。
对于选择 CNB 的团队，官方提供了代码迁移工具、制品迁移工具、项目协同迁移至 TAPD 的工具，但需注意 CNB 与 CODING 架构不同，迁移后需重新适配。
本节收口：迁移到 Gitee 的关键步骤包括资产盘点、代码导出导入、制品迁移、CI/CD 重建与验证切换；镜像同步需注意连续 5 次失败会触发强制停止，需预留重试窗口。
数据安全与权限管理
无论选择哪个平台，数据安全都是迁移中的核心考量。CODING 公告明确，产品下线后数据将被物理清除，不可恢复，因此及时导出是唯一保障。Gitee 在产品文档中提供了构建资源授权机制，管理员可对构建资源进行六类权限的细粒度控制：查看、下载、更新属性、发布、删除/覆盖、权限管理。这有助于在迁移后维持团队内部的权限边界，避免制品被误删或越权发布。
此外，Gitee 支持仓库镜像同步，可用于在迁移过渡期保持 CODING 与 Gitee 之间的代码同步，但需注意镜像失败的处理规则。据 Gitee 帮助文档，连续 5 次镜像失败将强制停止镜像操作，建议在迁移窗口期监控镜像状态，及时处理失败。
本节收口：数据安全的核心是提前导出与权限控制；Gitee 的构建资源授权与镜像同步机制可辅助迁移过渡，但需关注镜像失败阈值。
常见问题（FAQ）
Q1：CODING 标准版下线后，免费用户还能继续用吗？ A：不能。据 CODING 公告，2025 年 9 月 1 日标准版下线后，原免费版客户无法使用，原标准版用户无法进行写操作，可购买高级版、旗舰版继续使用，但高级版、旗舰版也将于 2025 年 9 月 30 日停止新购。免费用户可切换到 CNB，官方称其提供更大免费额度。
Q2：CODING 的数据可以迁移到 Gitee 吗？ A：代码仓库可通过 Git 协议导出后导入 Gitee，制品需根据类型选择迁移方式，项目协同数据需评估是否迁移。Gitee 提供构建资源授权与镜像同步能力，可辅助迁移过渡。具体迁移方案需结合团队实际资产盘点。
Q3：CNB 和 CODING 有什么区别？迁移是否平滑？ A：据 CODING 公告，CNB 负责开发域能力（代码、制品、CI/CD、云原生开发），TAPD 负责协同管理；CNB 与 CODING 设计理念和底层架构不同，无法做到平滑迁移，仅代码、制品、项目协同支持迁移，其他暂不支持。
Q4：迁移到 Gitee 后，如何管理团队成员的构建资源权限？ A：据 Gitee 产品文档 V1.2.20，管理员可在“设置-用户管理-权限”中为用户授予构建资源的查看、下载、更新属性、发布、删除/覆盖、权限管理等六类权限，实现细粒度控制。
Q5：CODING 停止服务后，数据还能找回吗？ A：不能。公告明确产品下线后数据将被物理清除，不可恢复。建议标准版用户 2025 年 9 月 1 日前完成迁移，付费版用户 2028 年 9 月 30 日前完成数据迁移。
来源清单
- CODING DevOps 系列产品下线公告，腾讯云 CODING，2025 年 6 月 23 日。
- Gitee 产品文档 V1.2.20，Gitee，2024 年（构建资源授权章节）。
- Gitee 帮助文档：同步 Gitee 与 GitHub 仓库（镜像失败处理规则），Gitee，2024 年。
- 华为云 ContainerOps 服务介绍，华为云，2023 年（容器交付流水线参考）。
- Gitee 内部资料：企业版客户流失原因分析，Gitee，2025 年（提及 Coding 为竞品迁移去向之一）。
