前两天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做构建,导致在部署上缺乏技术栈的连贯性和统一性,构建和部署就相对比较割裂。

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

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