雲效（原RDC）如何耦合進我們的業務

最近在将公司的持續內建架構做一個系統的調整，調整過程中受到了RDC團隊大量的幫助，是以利用國慶時間寫了幾篇RDC的分享，希望能讓更多的人了解和用好RDC這個産品。

我會把我最近3個月的使用體會分成5個部分：使用RDC的動機、PHP項目內建、JS項目內建、JAVA項目內建、Docker類項目內建這5個分支來寫

因為近期RDC的疊代比較頻繁，是以我的分享會比較的淺，點到為止，僅供參考，目錄：

1、RDC如何耦合進我們的業務

2、如何建構一個基于Composer的PHP項目

3、如何建構一個基于NodeJS的前後端項目

4、如何建構一個基于Maven的Java項目

5、RDC + 容器服務完成持續內建

在沒有切入RDC之前，我們公司的持續內建主要是通過以下的方式進行全流程：

應用環境： 基于Docker叢集。

代碼存儲： 存放在 code.aliyun.com，阿裡基于gitlab搭建。

建構打包： 使用Jenkins來進行建構。

上線釋出： 部分通過Jenkins釋出，部分通過自定義腳本實作。

我們之前的開發方式是基于微服務的方式進行開發，是以雖然按項目進行人員分組，但是具體的開發、測試、運維智能都是面向微服務，導緻了代碼分支的管理上有更嚴格的要求。我們的每一個代碼庫（服務，也可以了解為應用）都分為3個分支 dev、rc、release ，含義如下：

dev 開發分支： 主要用于工程師們日常開發後的合并歸總，比如基于dev建立一個新分支 dev-hanmeimei 用來存放員工韓梅梅的相關代碼，當韓梅梅開發完成後，送出合并到dev分支即可。原則上不直接修改dev分支的内容，防止出現污染和沖突。dev裡的代碼會自動的釋出到日常測試環境，進行測試。

rc 預發分支： 當dev分支的内容通過測試後，從dev合并到rc，然後進行線上測試，完成預發。此分支也不可進行人為幹預和修改，隻接受合并請求。

release 線上分支： 正式代碼，rc線測完成後合并到release分支，此分支也不可進行人為幹預和修改，隻接受合并請求。有一種特殊情況支援直接幹預，比如線上出現了很嚴重的bug，再走一遍合并流程已經太遲了，直接拉release分支建立一個release-bug分支，然後把bug修複完成後直接與release合并。

因為各種各樣的原因，我們已經使用上述的架構大約18個月以上了，是以積累下的問題特别的多，有些問題忍忍也就過去了，有些問題卻逐漸帶來了嚴重的影響。

先從代碼管理方式來說，因為我們的代碼管理模式是dev--->rc--->release的方式，需要一層層的進行合并，而我們不能向所有技術人員開放所有分支的合并權限，那就意味着需要至少有一個人來進行代碼的審查及合并工作，這是一個人力成本的問題。

然後說說硬體投入，我們之前的jenkins服務一共有3個機器組成，1個管理，2個建構。這一套2核4G記憶體大概一年15000元左右，對公司來說屬于必要成本，談不上貴，但也不算便宜。

随着使用逐漸發現，特定時間的代碼push頻率提高，原有的建構機器出現資源争搶，後來就改成了錯時建構（不偵聽push），每5分鐘一次，對效率有着輕微的影響。

因為開發負責的服務/應用不一樣，從企業内部管理的角度來說，不可能給所有開發人員開啟所有代碼倉庫的權限，那必須要有人對開發、測試人員的git權限進行維護，這一點其實很痛苦。人員離職、入職時需要把某些員工移入倉庫，移出倉庫，還有時需要提權/降級。我們一直沒能解決這個問題，都是人肉維護git權限，比較累，效率也很低。

之前說過，我們有專人對代碼的合并進行審查和管理，但是因為快速疊代，導緻每天會頻繁的審查和接受合并。從代碼安全性角度來說這是不得已而為之的一件事，低效，但是安全。

另外，在版本釋出時，有些版本是自動釋出的，有些産品比較重要，需要手動進行釋出。這樣一來，釋出也需要牽扯一些精力，這個權限不可能下放給工程人員，但是放在PM或者PL手裡又産生了大量的流程時間成本，目前沒有很好的解決，還是人肉處理，比較累。

留意到阿裡雲的RDC産品主要是之前使用過阿裡雲的另一個産品CRP（據說今年即将停止維護了），他同樣支援類似jenkins的功能，而且無需自己提供伺服器。

一開始沒完全切換到CRP的原因是我們的業務需要Docker部署，CRP到中後期才對Docker完成支援，而那時我們已經切換到jenkins上去了，是以就擱置了。

RDC是一個阿裡雲提供的雲服務，目前是免費的，未來即便商業化，應該也會大幅度低于自建系統的成本，不用特别擔心。

它直接打通了阿裡雲Code可以完成觸發建構。

不需要自備額外的機器進行建構。僅此一項對我來說一年至少節省1.5萬元。

之前公司使用禅道等一些産品管理需求、BUG、文檔等，接入RDC後它自帶項目和産品管理，節約了辦公這塊的成本，且支援釘釘接入，手機使用還是蠻友善的。

代碼倉庫的權限問題一直使我們公司的心病，因為人員離職/入職導緻需要調整每一個倉庫的權限。同時我們又是微服務架構，導緻一個應用可能會有N個倉庫，調整起權限來簡直是心累。

慶幸的是，我們公司一直是全員通過釘釘辦公，而RDC支援對接釘釘及其組織架構。那麼通過RDC+釘釘我們做到了下面這些事情：

1.隻需要在釘釘裡維護員工入職、離職即可，離職後相關項目權限自動就沒了。（省心+1）

2.在RDC裡為你的阿裡雲Code代碼倉庫分好git組，然後把對應的釘釘使用者丢到某個組下即可完成批量授權/降級。（省心+2）

RDC接入釘釘這個功能，我和RDC&CRP團隊喊了快1年，總算是支援了，這也是我覺得RDC一定能更好用的一個主要原因，産品多了、業務複雜之後你才能體會到内部管理時的碎片化有多痛苦，而RDC+釘釘我覺得能有效緩解這種痛苦。

通過RDC可以完成整個持續內建的工作流，并且RDC的最新版本已經可以自定義流水線了，可以有針對性的完成建構、自動部署、手動部署、開關式部署。

一些不太重要的業務，在流水線裡設定成自動釋出，一些比較重要的業務設定成手動釋出。而且未來釋出相關的操作很可能在釘釘裡就能直接完成，這樣一來其實已經減少了大量的中間流程，變相提高了效率。

重要的是，可以針對性的設定多個流水線，相當靈活，而且現在的建構和部署自由度很高。

另外，釘釘聊天記錄可以直接轉RDC的項目需求，我覺得這個功能簡直好用到突破天際。

開篇就說到這裡，主要是聊一聊我們自己公司遇到的一些問題，以及為什麼選擇RDC。

上面寫的東西，可能有一部分大家能找到共鳴，也可能看完不知所雲，因為每個團隊遇到的問題是不同的，感受和痛點也不同。

我不是要向大家推銷RDC這個産品，那是阿裡雲團隊的事情，我也不覺得RDC是完美的，僅僅是因為我們選擇了RDC進行持續內建相關的工作，把這個過程分享給大家，僅供參考。

後面的幾個分享中偏技術性多一些，主要介紹一下建構過程中遇到的一些小坑及應對方式。