傳統企業如何打造統一的持續整合平臺

一、傳統行業打造統一持續整合平臺痛點

l   多團隊維護多套工具鏈，重複任務多、運維成本高。

l   各團隊交付流程不統一麼，重複造輪子，知識經驗無法共享。

l   各交付質量、標準不統一，難以形成統一的度量體系。

二、從零到一的解決方案

1.  成立團隊

該團隊初期視公司技術人員規模，可由虛擬組或專屬devops工程師組成。該需要具備下述能力：

l   對需求管理、敏捷有所瞭解，敏捷教練最佳。

l   各語言研發專家，制定靜態程式碼檢測標準，負責公司技術棧選型。

l   測試工程師，負責測試工具選型及整合。

l   運維人員對資源及部署能力及流程進行把控。

l   需要與安全團隊聯合，對原始碼安全及外部元件安全形成統一方案。

l   由技術運營負責持續整合平臺建設成本及收益做評估。

2.  打造工具鏈

    由上述團隊對工具鏈選型，對整個軟體生命週期全流程進行工具鏈選型，選型可參考下圖，工具能力要覆蓋需求管理、開發、構建、測試、釋出、部署、運維及監控等多個領域。

3. 解決持續整合平臺在推廣中遇到的問題

問題一：開發團隊不配合怎麼辦？

答：構建統一的平臺，為不同團隊提供全方位的基礎平臺，減少開發團隊自己的運維成本。曉之以情、動之以禮，如果仍然沒效果，做詳細的資源使用及度量痛點，自上而下調動研發團隊配合。

問題二：開發團隊擔心學習新平臺投入時間成本較高怎麼辦？

答：編寫統一的持續整合模版，對開發人員模版化或桌面化提供持續整合服務，讓開發人員透過簡單的呼叫或拖拽就能實現複雜的持續整合流水線，不必要去學習大量的指令碼語言。（如jenkins的sharelibrary）

問題三：開發團隊不安規範使用怎麼辦？

答：回收持續整合平臺許可權，讓外包或自有研發人員無法對構建模版進行修改，強制每一次持續整合要進行完整的測試和掃描步驟，保障每一個質量關卡都被觸發。

4. 推廣的方式

試點團隊先行：試點團隊儘量選擇關係比較好的、邊緣業務團隊，先行團隊要儘量踩雷、快速反饋，驗證工具鏈及管理方案的可行性，快速迭代工具鏈及模版內容。

小範圍試用：小範圍試用是為了驗證平臺的通用性，保障平臺能適配大多數技術棧。並在試用中持續接受各團隊的反饋，持續迭代平臺功能。同時要在該階段定義度量指標及使用標準。

集團推廣：真正實現統一管理，並繼續持續改進。

5. 持續整合過程中的後設資料管理

統一編寫模版後需要在模版中強制收集軟體生命週期各個工具鏈產生的資料，我們把這個資料稱之為軟體的後設資料。後設資料包括但不限於：需求id、開發者資訊、構建環境、依賴元件、測試報告、靜態掃描結果、安全掃描結果、部署資訊等。最終這些資料將會作為評判此版本的質量關卡，確保每次交付都是高質量的交付。

6. 持續整合過程中的安全管理

儘量做到安全掃描左移，在開發側引入安全掃描，對外部依賴及原始碼做掃描，儘量避免漏洞在未被測試掃描情況下被引入到生產線上。這樣不會造成高危漏洞在生產線上被發現而導致的整個開發迭代過程要重新進行的低效情景。

三、總結

        打造傳統企業統一的持續整合平臺，需要專門的團隊打造合適的工具鏈，並制定合理的規範及度量標準，最終透過不同的方式推廣到整個集團。