前兩天CODING DevOps宣布產(chǎn)品下線，建議標(biāo)準(zhǔn)版用戶2025年9月1前完成遷移、付費(fèi)版用戶2028年9月30日前完成數(shù)據(jù)遷移。有點(diǎn)突然，但也不意外，我是接觸Coding最早的用戶，經(jīng)常作為學(xué)習(xí)研究的對(duì)象。

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

一年前，官方推薦的平替https://cnb.cool/就已經(jīng)在Coding上出現(xiàn)，在代碼庫(kù)模塊做些云原生構(gòu)建相關(guān)的嘗試。我就預(yù)感到他們?cè)谔剿饕环N新的構(gòu)建引擎-云原生構(gòu)建，畢竟Coding底層引擎是基于Jenkins開(kāi)發(fā)的，有點(diǎn)英雄垂暮的感覺(jué)。

另外，在代碼分析/掃描，應(yīng)用管理模塊，他們也都在不停的嘗試新功能，有些還是Beta版本，但似乎沒(méi)有清晰的定位。

Coding的下線，某種意義上標(biāo)志著以“Jenkins”為底層引擎的商業(yè)平臺(tái)已經(jīng)退出歷史舞臺(tái)。一種新的，基于云原生的構(gòu)建方式已經(jīng)逐漸成為市場(chǎng)主流，從最早的GitLab到阿里云效，華為CodeArts，包括開(kāi)源Drone, Tekton，都在說(shuō)明這一切。

如下圖，從近三年的調(diào)研來(lái)看，云原生CI/CD工具有明顯增長(zhǎng)，jenkins雖然占有率依然很高，多半還是因?yàn)槊赓M(fèi)，遍地的資料和悠久的“使用習(xí)慣”。

CODING DevOps的用戶怎么辦？

打開(kāi)知乎，就有人提問(wèn)Coding下線后是否可以遷移到它推薦的【云原生構(gòu)建】https://cnb.cool/。

作為長(zhǎng)期研究這些工具的實(shí)踐者，我感覺(jué)有必要寫(xiě)篇文章說(shuō)說(shuō)自己的看法，不打廣告，只是客觀幫大家分析下。

從功能模塊上，大致可以分為兩大類

管理類

比如，項(xiàng)目協(xié)同，測(cè)試管理都屬于項(xiàng)目管理類，市面上大概有如下產(chǎn)品替代，商業(yè)付費(fèi)類居多。由于Coding本身不是管理類起家，沒(méi)有絕對(duì)的市場(chǎng)地位（不像Jira），所以不會(huì)有快速遷移的方案，最多把需求/缺陷盡可能導(dǎo)出來(lái)再倒入新平臺(tái)。

對(duì)于標(biāo)準(zhǔn)版（免費(fèi)）用戶，估計(jì)這部分比重不是很大。

對(duì)于付費(fèi)用戶，官方還有3年的維護(hù)支持，可以長(zhǎng)遠(yuǎn)再考慮下，選擇一個(gè)“穩(wěn)定的”老牌廠商，管理類業(yè)務(wù)遷移不是個(gè)小事，除了單純技術(shù)問(wèn)題，還關(guān)系到未來(lái)企業(yè)的管理協(xié)同和配套流程。

工程類

工程類主要就圍繞“代碼”，“制品”，“流水線”，“環(huán)境”。由于技術(shù)架構(gòu)和邏輯差異巨大，基本這塊沒(méi)有太好的遷移方案，只能人肉一塊一塊去梳理，哪些需要哪些可以放棄重新建。

• ? 代碼部分：整體可以通過(guò)工具遷移，問(wèn)題不大

• ? 制品部分：整體也可以通過(guò)工具遷移保存，主要看制品庫(kù)的結(jié)構(gòu)，分類和規(guī)模

• ? 環(huán)境：這個(gè)看是騰訊云的，還是coding 私有化部署用的自己的環(huán)境，整體問(wèn)題也不大

• ? 流水線：包括持續(xù)集成/持續(xù)部署/應(yīng)用管理等和自動(dòng)化編排有關(guān)的，由于依靠coding構(gòu)建引擎，大概率是要重新編寫(xiě)和組織的。如果準(zhǔn)備繼續(xù)使用Jenkins, 可能工作量相對(duì)少點(diǎn)，原有的Jenkinsfile還能用；如果準(zhǔn)備放棄jenkinsfile, 那么編排都需要重新組織編寫(xiě)，具體看原有流水線數(shù)量規(guī)模，標(biāo)準(zhǔn)化規(guī)范度而定。

至于這塊可以平替的工具平臺(tái)，要不就是商業(yè)全家桶（國(guó)內(nèi)云廠商都有，或者云原生商業(yè)平臺(tái)），要不就是開(kāi)源工具集合。

• ? 如果選擇商業(yè)全家桶，除了費(fèi)用，就需要按照人家的規(guī)則去玩，需要點(diǎn)學(xué)習(xí)成本

• ? 如果開(kāi)業(yè)工具集合，比如繼續(xù)用Jenkins，我覺(jué)得對(duì)于小企業(yè)，沒(méi)太多預(yù)算的，“gitlab+jenkins+nexus” 三件套也夠用，對(duì)比遷移學(xué)習(xí)成本還會(huì)低一點(diǎn)。如果放棄jenkins, "gitlab+ nexus/harbor" 組合，也可以，連需求/缺陷管理都包含了。

最后

對(duì)于Coding的下線，還是挺惋惜的。從產(chǎn)品的設(shè)計(jì)和交互邏輯上，體驗(yàn)還是不錯(cuò)的，功能模塊也很完整。可能由于底層嚴(yán)重依賴Jenkins做構(gòu)建，導(dǎo)致在部署上缺乏技術(shù)棧的連貫性和統(tǒng)一性，構(gòu)建和部署就相對(duì)比較割裂。

新的【云原生構(gòu)建】代表了未來(lái)的“軟件開(kāi)發(fā)工程化”的趨勢(shì)，一切皆代碼！基礎(chǔ)設(shè)施的迭代升級(jí)，使用看似簡(jiǎn)單，實(shí)則工程化的思想越發(fā)深厚，同樣也要求技術(shù)架構(gòu)和研發(fā)人員的工程素養(yǎng)持續(xù)提升。

最后想說(shuō)，企業(yè)在選擇平臺(tái)時(shí)候，走一步看三步。商業(yè)產(chǎn)品都是有自己的生命周期，如何在它結(jié)束的時(shí)候，企業(yè)自己的業(yè)務(wù)如何快速切換，給自己留點(diǎn)余地，這個(gè)是要平臺(tái)建設(shè)者思考的。

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