前面一章節我們已經了解了Agile,CI/CD,DevOps，作為DevOps的起點，對于一個團隊，如何開始自己的持續集成？根據我的經驗，列出了一下需要考慮的點
1. 代碼管理/分支策略
- 代碼托管在哪里？
- 使用git or svn?
- 分支策略/分支模型？
- CI 服務可以訪問您的代碼庫嗎？
- 代碼結構如何？需要一個庫，還是多個庫？
- 版本號定義？
- 依賴管理？命名規則？
- Code Review ?
2. 持續集成服務器
- 選好你需要的CI server了嗎？ jenkins, Teamcity,GoCD or AuzreDevOps
- CI Server 使用的學習
- CI Server 如何部署，需要多少資源，需要多少并發job ?
- Pipeline編寫，如何標準化？是否需要參數化？
- 與代碼倉庫，制品庫集成？
- 靜態代碼檢查？SonarQube
- 多分支/多個倉庫，相互依賴？
3. 制品庫
- 選擇合適的制品庫服務器 (jar, npm, nuget, Docker or other package ?)
- 制品的版本？ 如何與code commit id 關聯？
- 制品庫保存策略/tag 管理
4. 測試類型
CI階段除了保證代碼沒有沖突，編譯通過之外，最重要的就是測試 。每次代碼變更后，我們需要自動運行測試用例。
在初始階段并不需要實現所有的測試類型。一開始可以以單元測試入手，隨著時間擴展覆蓋面。
- 單元測試：范圍非常小，驗證每個獨立方法級別的操作。
- 集成測試：保證模塊間運行正常，包括多個模塊、多個服務。
- 驗收測試：與集成測試類似，但是僅關注業務 case，而不是模塊內部本身。
- UI 測試：從用戶的角度保證呈現正確運行。
并不是所有的測試都是對等的，實際運行中可以做些取舍。
4級測試規劃
image.png
- 單元測試實現起來既快成本又低，因為它們主要是對小代碼塊進行檢查。
- UI 測試實施起來很復雜，運行起來很慢，因為它通常需要啟動一個完整的環境以及多個服務來模擬瀏覽器或移動行為。實際情況可能希望限制復雜的 UI 測試的數量，并依賴基礎上良好的單元測試來快速構建，并盡快獲得開發人員的反饋。
- 單元測試前期投入少，短期內可以看到效果，對開發人員要求高；UI測試前期人員成本投入大，需要很長時間看到效果
代碼覆蓋率
- 使用代碼覆蓋率查找未測試的代碼。一旦您采用了自動化測試，最好將它與一個測試覆蓋工具結合起來，幫助了解測試套件覆蓋了多少代碼庫。代碼覆蓋率定在 80%以上是很好的，但要注意不要將高覆蓋率與良好的測試套件混淆。代碼覆蓋工具將幫助您找到未經測試的代碼，但在一天結束的時候，測試的質量會產生影響。如果剛開始，不要急于獲得代碼庫的 100%覆蓋率，而是使用測試覆蓋率工具來找出應用程序的關鍵部分，這些部分還沒有測試并從那里開始。
- 重構是一個添加測試的機會。如果您將要對應用程序進行重大更改，那么應該首先圍繞可能受到影響的特性編寫驗收測試。這將為您提供一個安全網，以確保在重構代碼或添加新功能后，原始行為不會受到影響。
5. 測試/部署環境準備
- 測試需要多少資源 ？
- 編寫自動化部署腳本？ Python,shell, powershell, or ansible ?
- 多環境/多分支 配置？
6. 團隊CI文化
- 當團隊實踐 CI 時，需要了解分支模型，按照定義的commit 策略，進行頻繁提交
- 提交沖突了，如何處理？
- 怎么反饋沖突 或者build break ? 誰處理？
- 推廣普及CI文化盡早集成。如果很長時間不合并代碼，代碼沖突的風險就越高，代碼沖突的范圍就越廣。如果發現某些分支會影響已經存在的分支，需要增加發布關閉標簽，避免發布時兩個分支沖突。保證編譯時時刻刻暢通。一旦發現任何編譯問題，立刻修復，否則可能會帶來更多的錯誤。測試套件需要盡快反饋測試結果，或者優先返回短時間測試（單元測試）的結果，否則開發者可能就切換回開發了。一旦編譯出錯，需要通知給開發者，或者更進一步給出一個 dashboard，每個人都可以在這里查看編譯結果。把測試用例納入流程的一部分。確保每個分支都有自動化測試用例。似乎編寫測試用例拖慢了項目節奏，但是它可以減少回歸時間，減少每次迭代帶來的 bug。而且每次測試通過后，將會非常有信息合并到主干分支，因為新增的內容不影響以前的功能。修 bug 的時候編寫測試用例。把 bug 的每個場景都編寫成測試用例，避免再次出現。
歡迎關注我的微信公眾號 - DevOps實踐之路
