背景：

DevOps已經成為軟體開發領域一個炙手可熱的名詞。敏捷開發、持續交付、CI/CD，K8s…這些主流的開發理念、工具無一例外都與DevOps有著很強的聯絡。這種環境影響下，傳統的運維團隊均開始向DevOps進行轉型。一時之間運維開發、SRE、工程效能工程師需求量大增，無論公司大小，都會開始著手DevOps的從0到1的建設。我們開始搭建工具鏈、部署流水線、整合自動化測試工具、開發自動化釋出系統……一切的一切都是為了完善我們自動化體系，從而提高開發效率，最佳化產品質量。

那麼問題來了，你團隊所建設的DevOps體系，已經是完善的DevOps了麼？

 

正文：

    我們如何去評估目前DevOps中持續交付的建設情況呢，這裡筆者總結了一些我們在DevOps初期應該進行的一些工作，這些工作大多數屬於工具鏈的整合，我們可以對照下述十四條關卡，來驗證一下我們的DevOps建設中持續交付這一環節是否走在了一條正確的道路上吧。

 

1. 版本控制

版本控制是指透過記錄軟體開發過程中的原始碼、配置資訊、環境、資料等，快速的恢復及訪問任意一個版本。版本控制最主要的功能就是追蹤檔案的變更。

常用版本管理工具： git

2.  最優分支策略

分支的種類很多，大多數團隊會使用到主幹分支、開發分支、臨時分支、功能分支、預釋出分支、bug修復分支等等。那麼如何選擇一個最優分支策略，是我們開發團隊必須去規範的一件事。分支策略與版本釋出頻率之間有一定的相關性，我們要根據自己團隊開發模式以及專案迭代週期來選擇最優的分支策略。

3.  程式碼靜態掃描

程式碼靜態掃描需要從下面幾個維度進行檢查：複雜度分佈、重複程式碼、單元測試統計、程式碼規則檢查、註釋率、潛在BUG、結構與設計。透過在構建pipeline中加設程式碼靜態掃描的質量關卡，確保我們的程式碼可以達到一個可釋出的級別。

常用的程式碼靜態掃描工具：如 SonarQube。

4. 80%以上單元測試覆蓋率

提高單元測試的意義最重要的一點是保證程式碼所對應的功能正常、而單元測試覆蓋率的檢查是以一種約束方式來規範開發人員使用單元測試，透過設定單元測試覆蓋率的關卡來保障開發程式碼的正確性，並讓單元測試逐漸地變成開發習慣。

5.  漏洞掃描

每個專案中，高達99.9%的程式碼來自於外部依賴，為了避免重複造輪子，我們引用了大量的外部開源框架及元件，這些外部依賴是否有安全，是否存在高危漏洞，開發人員一般是無法關注到的，所以我們需要一款產品可以整合到我們開發的IDE、設定成為構建流程pipeline中的質量關卡、無縫的對接到我們的製品庫中，來掃描我們所有的外部依賴。

常用漏洞掃描工具： JFrog Xray

6. 製品管理

製品是構建過程的產出物。包括軟體包、測試報告、應用配置檔案等。製品管理是對軟體研發過程中生成的產物的管理，一般作為最終交付物完成釋出和交付。你所管理的製品可以統稱為二進位制檔案，製品倉庫則可以提供所有二進位制檔案的管理能力，提供全語言的依賴解析能力以及收集整個軟體生命週期的資訊與製品關聯。

常用製品管理倉庫： Artifactory

7.  開源協議掃描

開源協議有上百種，寬鬆程度不一。是否允許商用、是否可以修改、修改後是否需要繼續開源等都是每種協議特有的特性。我們作為使用者，作為開發者，為了提高開發效率，避免重複造輪子，難免會引用大量的外部元件及框架，那我們在DevOps建設過程中則必須注意對開源協議的管理及掃描。

常用的開源協議：

l   Apache 2：直接使用須保留原始許可宣告，若對其進行修改，需向使用者說明。

l   MIT：必須保留原始許可證宣告

l   BSD：必須保留原始許可證宣告，部分版本不得使用原作者姓名用於軟體銷售

l   GPL：若包涵GPL程式碼，整個專案則必須使用GPL許可證。

常用的協議掃描工具： JFrog Xray。

8. 不可變基礎設施

不可變基礎設施是指任何基礎設施例項在部署後永遠不會被修改。如果需要以任何方式更新，修復或修改某些內容，則會使用一批新的例項去替換，並在經過驗證後，將新的基礎設施例項上線，替換掉舊的例項。這種在當年在物理機或虛擬機器上無法快速實現的這種不可變基礎設施的理念，隨著docker的普及正在飛快的發展，我們可以透過容器的方式快速的實現。這種模式可以為我們減少配置管理的負擔，並使得 DevOps 更加容易實踐

最佳實踐方式： Docker

9. 整合測試

      整合測試是在單元測試的基礎上，把軟體單元按照軟體概要設計規格說明的規格要求，組裝成模組、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求。

10.   效能測試

效能測試方法是透過模擬生產執行的業務壓力量和使用場景組合，來測試系統的效能是否滿足軟體的效能要求。通俗地說，這種方法就是要在特定的執行條件下驗證軟體系統的處理能力。

落地方式包括但不限於下述幾點：

l   運維人員、對應的開發及測試人員、產品經理等微信通知

l   大屏滾動播放最近的變更記錄

l   變更記錄同步到監控系統

功能開關概念很容易理解，透過功能開關我們可以在執行過程中對某一功能進行啟動和關閉，在敏捷開發模式下，為了快速迭代，在某些團隊沒有完全準備好的情況下，我們可以透過功能開關的方式將新功能上線並透過配置遮蔽該功能，直至所有團隊準備就緒，整個功能涉及到的服務全部上線後，可以開啟此功能開關，提供使用者使用。

透過功能開關的方案，我們可以快速迭代，不必進行復雜的整合測試及大版本交付，實現真正的敏捷開發、小步快跑。

13. 較高的介面測試覆蓋率

提高介面測試覆蓋率就意味著我們可以提高自動化測試的覆蓋率，在每次構建流水線中可以自動部署我們的專案，透過介面測試來實現基礎的自動化測試。另外介面測試可以提供給運維平臺一個監控服務是否穩定的依據，我們可以透過監控平臺實時觸發介面測試，來判斷線上的服務是否依然穩定執行。透過這種介面測試，我們可以最快的速度定位到某些線上某些功能的故障。

14. 零停機發布

無論使用藍綠部署、還是金絲雀釋出，我們的目標只有一個，就是零停機發布。零停機發布是指在對使用者不停止服務的前提下進行版本的迭代，修復bug、引用新功能等操作。是否擁有一個健全的零停機發布體系也將是我們DevOps建設中十分重要的一個步驟。

 

 

總結：

    DevOps並不是我們建設起來工具鏈就可以實踐的一個理念，文中所介紹的十四個關卡也僅僅是DevOps體系中小小的一部分。開發團隊組織架構的合理性、安全風險管理能力、技術運營、需求管理、架構設計、工程師文化等都是我們DevOps建設過程中需要探討的課題。

 

更多技術分享請關注   JFrog傑蛙線上課堂

1月2日線上課堂：《版本控制管理與最佳實踐》

課堂收益：

1.        如何使用版本控制系統

2.        各種分支模型有什麼優缺點，什麼樣的分支模型更適用於您的環境

3.        版本控制應該遵循的一些標準

 

報名連結：

抽獎活動：

課堂結束前五分鐘，進行答題抽獎活動

第一名：小愛音響

第二名：JFrog傑蛙新版T恤

第三名：JFrog傑蛙新版T恤