你準備好開始DevOps了嗎？

前面一章節咱們已經瞭解了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級測試規劃#

• 單元測試實現起來既快成本又低，由於它們主要是對小代碼塊進行檢查。

• UI 測試實施起來很複雜，運行起來很慢，由於它一般須要啓動一個完整的環境以及多個服務來模擬瀏覽器或移動行爲。實際狀況可能但願限制複雜的 UI 測試的數量，並依賴基礎上良好的單元測試來快速構建，並儘快得到開發人員的反饋。

• 單元測試前期投入少，短時間內能夠看到效果，對開發人員要求高；UI測試前期人員成本投入大，須要很長時間看到效果

代碼覆蓋率#

• 使用代碼覆蓋率查找未測試的代碼。一旦您採用了自動化測試，最好將它與一個測試覆蓋工具結合起來，幫助瞭解測試套件覆蓋了多少代碼庫。代碼覆蓋率定在 80%以上是很好的，但要注意不要將高覆蓋率與良好的測試套件混淆。代碼覆蓋工具將幫助您找到未經測試的代碼，但在一天結束的時候，測試的質量會產生影響。若是剛開始，不要急於得到代碼庫的 100%覆蓋率，而是使用測試覆蓋率工具來找出應用程序的關鍵部分，這些部分尚未測試並從那裏開始。
• 重構是一個添加測試的機會。若是您將要對應用程序進行重大更改，那麼應該首先圍繞可能受到影響的特性編寫驗收測試。這將爲您提供一個安全網，以確保在重構代碼或添加新功能後，原始行爲不會受到影響。

5. 測試/部署環境準備#

• 測試須要多少資源 ？
• 編寫自動化部署腳本？ python,shell, powershell, or ansible ?
• 多環境/多分支 配置？

6. 團隊CI文化#

• 當團隊實踐 CI 時，須要瞭解分支模型，按照定義的commit 策略，進行頻繁提交
• 提交衝突了，如何處理？
• 怎麼反饋衝突 或者build break ? 誰處理？

• 推廣普及CI文化

  1.  儘早集成。若是很長時間不合並代碼，代碼衝突的風險就越高，代碼衝突的範圍就越廣。若是發現某些分支會影響已經存在的分支，須要增長髮布關閉標籤，避免發佈時兩個分支衝突。
  2.  保證編譯時時刻刻暢通。一旦發現任何編譯問題，馬上修復，不然可能會帶來更多的錯誤。測試套件須要儘快反饋測試結果，或者優先返回短期測試（單元測試）的結果，不然開發者可能就切換回開發了。一旦編譯出錯，須要通知給開發者，或者更進一步給出一個 dashboard，每一個人均可以在這裏查看編譯結果。
  3.  把測試用例歸入流程的一部分。確保每一個分支都有自動化測試用例。彷佛編寫測試用例拖慢了項目節奏，可是它能夠減小回歸時間，減小每次迭代帶來的 bug。並且每次測試經過後，將會很是有信息合併到主幹分支，由於新增的內容不影響之前的功能。
  4.  修 bug 的時候編寫測試用例。把 bug 的每一個場景都編寫成測試用例，避免再次出現。
  5.