CODING DevOps服务下线，受影响企业何去何从？如何进行迁移？

前两天CODING DevOps宣布产品下线，建议标准版用户2025年9月1前完成迁移、付费版用户2028年9月30日前完成数据迁移。有点突然，但也不意外，我是接触Coding最早的用户，经常作为学习研究的对象。

https://coding.net/help/docs/admin/pay/price-adjustment.html

一年前，官方推荐的平替https://cnb.cool/就已经在Coding上出现，在代码库模块做些云原生构建相关的尝试。我就预感到他们在探索一种新的构建引擎-云原生构建，毕竟Coding底层引擎是基于Jenkins开发的，有点英雄垂暮的感觉。

另外，在代码分析/扫描，应用管理模块，他们也都在不停的尝试新功能，有些还是Beta版本，但似乎没有清晰的定位。

Coding的下线，某种意义上标志着以“Jenkins”为底层引擎的商业平台已经退出历史舞台。一种新的，基于云原生的构建方式已经逐渐成为市场主流，从最早的GitLab到阿里云效，华为CodeArts，包括开源Drone, Tekton，都在说明这一切。

如下图，从近三年的调研来看，云原生CI/CD工具有明显增长，jenkins虽然占有率依然很高，多半还是因为免费，遍地的资料和悠久的“使用习惯”。

CODING DevOps的用户怎么办？

打开知乎，就有人提问Coding下线后是否可以迁移到它推荐的【云原生构建】https://cnb.cool/。

作为长期研究这些工具的实践者，我感觉有必要写篇文章说说自己的看法，不打广告，只是客观帮大家分析下。

从功能模块上，大致可以分为两大类

管理类

比如，项目协同，测试管理都属于项目管理类，市面上大概有如下产品替代，商业付费类居多。由于Coding本身不是管理类起家，没有绝对的市场地位（不像Jira），所以不会有快速迁移的方案，最多把需求/缺陷尽可能导出来再倒入新平台。

对于标准版（免费）用户，估计这部分比重不是很大。

对于付费用户，官方还有3年的维护支持，可以长远再考虑下，选择一个“稳定的”老牌厂商，管理类业务迁移不是个小事，除了单纯技术问题，还关系到未来企业的管理协同和配套流程。

工程类

工程类主要就围绕“代码”，“制品”，“流水线”，“环境”。由于技术架构和逻辑差异巨大，基本这块没有太好的迁移方案，只能人肉一块一块去梳理，哪些需要哪些可以放弃重新建。

• • 代码部分：整体可以通过工具迁移，问题不大

• • 制品部分：整体也可以通过工具迁移保存，主要看制品库的结构，分类和规模

• • 环境：这个看是腾讯云的，还是coding 私有化部署用的自己的环境，整体问题也不大

• • 流水线：包括持续集成/持续部署/应用管理等和自动化编排有关的，由于依靠coding构建引擎，大概率是要重新编写和组织的。如果准备继续使用Jenkins, 可能工作量相对少点，原有的Jenkinsfile还能用；如果准备放弃jenkinsfile, 那么编排都需要重新组织编写，具体看原有流水线数量规模，标准化规范度而定。

至于这块可以平替的工具平台，要不就是商业全家桶（国内云厂商都有，或者云原生商业平台），要不就是开源工具集合。

• • 如果选择商业全家桶，除了费用，就需要按照人家的规则去玩，需要点学习成本

• • 如果开业工具集合，比如继续用Jenkins，我觉得对于小企业，没太多预算的，“gitlab+jenkins+nexus” 三件套也够用，对比迁移学习成本还会低一点。如果放弃jenkins, "gitlab+ nexus/harbor" 组合，也可以，连需求/缺陷管理都包含了。

最后

对于Coding的下线，还是挺惋惜的。从产品的设计和交互逻辑上，体验还是不错的，功能模块也很完整。可能由于底层严重依赖Jenkins做构建，导致在部署上缺乏技术栈的连贯性和统一性，构建和部署就相对比较割裂。

新的【云原生构建】代表了未来的“软件开发工程化”的趋势，一切皆代码！基础设施的迭代升级，使用看似简单，实则工程化的思想越发深厚，同样也要求技术架构和研发人员的工程素养持续提升。

最后想说，企业在选择平台时候，走一步看三步。商业产品都是有自己的生命周期，如何在它结束的时候，企业自己的业务如何快速切换，给自己留点余地，这个是要平台建设者思考的。

本文使用 文章同步助手 同步