575
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個月以上了，所以積累下的問題特別的多，有些問題忍忍也就過去了，有些問題卻逐漸帶來了嚴重的影響。
1.成本問題
先從代碼管理方式來說，因為我們的代碼管理模式是dev--->rc--->release的方式，需要一層層的進行合並，而我們不能向所有技術人員開放所有分支的合並權限，那就意味著需要至少有一個人來進行代碼的審查及合並工作，這是一個人力成本的問題。
然後說說硬件投入，我們之前的jenkins服務一共有3個機器組成，1個管理，2個構建。這一套2核4G內存大概一年15000元左右，對公司來說屬於必要成本，談不上貴，但也不算便宜。
隨著使用逐漸發現，特定時間的代碼push頻率提高，原有的構建機器出現資源爭搶，後來就改成了錯時構建（不偵聽push），每5分鍾一次，對效率有著輕微的影響。
2.管理問題
因為開發負責的服務/應用不一樣，從企業內部管理的角度來說，不可能給所有開發人員開啟所有代碼倉庫的權限，那必須要有人對開發、測試人員的git權限進行維護，這一點其實很痛苦。人員離職、入職時需要把某些員工移入倉庫，移出倉庫，還有時需要提權/降權。我們一直沒能解決這個問題，都是人肉維護git權限，比較累，效率也很低。
3.效率問題
之前說過，我們有專人對代碼的合並進行審查和管理，但是因為快速迭代，導致每天會頻繁的審查和接受合並。從代碼安全性角度來說這是不得已而為之的一件事，低效，但是安全。
另外，在版本發布時，有些版本是自動發布的，有些產品比較重要，需要手動進行發布。這樣一來，發布也需要牽扯一些精力，這個權限不可能下放給工程人員，但是放在PM或者PL手裏又產生了大量的流程時間成本，目前沒有很好的解決，還是人肉處理，比較累。
三、帶著問題出發，通過RDC完成持續集成
留意到阿裏雲的RDC產品主要是之前使用過阿裏雲的另一個產品CRP（據說今年即將停止維護了），他同樣支持類似jenkins的功能，而且無需自己提供服務器。
一開始沒完全切換到CRP的原因是我們的業務需要Docker部署，CRP到中後期才對Docker完成支持，而那時我們已經切換到jenkins上去了，所以就擱置了。
1.通過RDC有效降低成本
RDC是一個阿裏雲提供的雲服務，目前是免費的，未來即便商業化，應該也會大幅度低於自建係統的成本，不用特別擔心。
它直接打通了阿裏雲Code可以完成觸發構建。
不需要自備額外的機器進行構建。僅此一項對我來說一年至少節省1.5萬元。
之前公司使用禪道等一些產品管理需求、BUG、文檔等，接入RDC後它自帶項目和產品管理，節約了辦公這塊的成本，且支持釘釘接入，手機使用還是蠻方便的。
2.通過RDC解決管理問題
代碼倉庫的權限問題一直使我們公司的心病，因為人員離職/入職導致需要調整每一個倉庫的權限。同時我們又是微服務架構，導致一個應用可能會有N個倉庫，調整起權限來簡直是心累。
慶幸的是，我們公司一直是全員通過釘釘辦公，而RDC支持對接釘釘及其組織架構。那麼通過RDC+釘釘我們做到了下麵這些事情：
1.隻需要在釘釘裏維護員工入職、離職即可，離職後相關項目權限自動就沒了。（省心+1）
2.在RDC裏為你的阿裏雲Code代碼倉庫分好git組，然後把對應的釘釘用戶丟到某個組下即可完成批量授權/降權。（省心+2）
RDC接入釘釘這個功能，我和RDC&CRP團隊喊了快1年，總算是支持了，這也是我覺得RDC一定能更好用的一個主要原因，產品多了、業務複雜之後你才能體會到內部管理時的碎片化有多痛苦，而RDC+釘釘我覺得能有效緩解這種痛苦。
3.通過RDC解決效率問題
通過RDC可以完成整個持續集成的工作流，並且RDC的最新版本已經可以自定義流水線了，可以有針對性的完成構建、自動部署、手動部署、開關式部署。
一些不太重要的業務，在流水線裏設置成自動發布，一些比較重要的業務設置成手動發布。而且未來發布相關的操作很可能在釘釘裏就能直接完成，這樣一來其實已經減少了大量的中間流程，變相提高了效率。
重要的是，可以針對性的設置多個流水線，相當靈活，而且現在的構建和部署自由度很高。
另外，釘釘聊天記錄可以直接轉RDC的項目需求，我覺得這個功能簡直好用到突破天際。
四、備注
開篇就說到這裏，主要是聊一聊我們自己公司遇到的一些問題，以及為什麼選擇RDC。
上麵寫的東西，可能有一部分大家能找到共鳴，也可能看完不知所雲，因為每個團隊遇到的問題是不同的，感受和痛點也不同。
我不是要向大家推銷RDC這個產品，那是阿裏雲團隊的事情，我也不覺得RDC是完美的，僅僅是因為我們選擇了RDC進行持續集成相關的工作，把這個過程分享給大家，僅供參考。
後麵的幾個分享中偏技術性多一些，主要介紹一下構建過程中遇到的一些小坑及應對方式。
博客原文：https://qipangzi.com/archives/79
最後更新：2017-10-09 22:34:19