爲團隊構建DevOps體系

DevOps是什麼

DevOps的定義衆說紛紜，我的的理解是：

• 從狹義上來講是一套實踐、方法、工具，是提升交付應用程序和服務能力的一組最佳實踐，爲了在保證高質量的前提下縮短系統變動從提交到部署至生產環境的時間。
• 從廣義上來講是一個運動，一種文化，強調團隊緊密合做，打破角色之間的隔閡從而達到提升最終交付價值。

爲何要構建DevOps體系

因此，咱們須要：

• 將應用部署的流程自動化起來，只須要按一個按鈕就能完成在任意環境上的部署
• 將開發、測試、部署環境統一塊兒來並管理起來
• 縮短從代碼提交到部署到生產環境之間的時間
• 將全部過程可視化起來，讓全部人知道當前的進展
• 將異常及時反饋給負責人並有回滾方式

DevOps體系的思路與實踐

思路：以提高開發部署效率這個結果爲導向，以標準化、自動化、可視化爲思想，以持續集成、持續交付、敏捷爲核心來構建一套DevOps體系。

首先咱們能夠用上圖中的內容與本身當前的工做環境進行對比，還差哪些部分，咱們就補充哪些，依靠木桶效應，優先實現還未存在的部分，優先將體系的基礎構建完成。

固然圖中的實踐也不完整，能夠參考下面的一些實踐來開始。

自動化流水線（持續集成）

優先級：高

經過使用自動化流水線構建工具將代碼的構建、測試、部署的流程規範起來，將執行的操做固定下來，去除人爲因素干擾構建流程，從代碼的提交到部署造成一條生產線。

前置條件：

• 分支策略。流水線的構建方式是經過分支策略來定的，若是有master、dev、release分支，則可能須要構建出三套流水線來分別管理這三個分支
• 提交策略。不管是否使用持續集成的方式提交，提交的信息必須統一，提交者的姓名、提交所屬的功能、提交的內容這三塊內容必需要有
• 部署步驟。肯定須要部署到哪些環境中，有幾個構建的步驟，如test、build、deployDev、deployTest、deployProd
• 多項目的結構。一個項目須要是一個能讓git單獨追蹤的項目，才能避免在自動化中影響其餘項目的構建

準備好前置條件以後就能夠開始構建第一條流水線了，具體的構建工具與構建步驟因團隊而異，具體構建的過程就是將全部當前的部署流程整理進構建流水線中，並使用相似Jenkinsfile這樣的Pipieline as code的形式將流水線當作整個項目的一部分管理起來，所以這是工做量最大的部分。構建完成後還須要完成流水線可視化，在團隊工做區域的顯眼位置放置一臺顯示器，將當前全部流水線的工做狀態顯示在上面。

各類環境的管理

優先級：高

• 統一開發、測試、部署的環境。生產環境是什麼樣子，測試環境與開發環境就儘可能保持一致。應用的架構方式、應用運行所在的系統版本、應用運行所在的機器配置都應當保持一致，使用Docker能夠保證後二者沒有問題，但架構方式在開發環境難以作到，優先級其實不高，能夠暫時放下。
• 使用Ansible將構建虛擬機上各類工具、環境的過程代碼化從而實現Infrastructure as code，將部署的架構也體如今其中從而實現Platform as code，便於擴展機器、問題追溯、架構優化。
• 依賴包的管理。Java很是方便，能夠本身部署一個配置管理源，全部包都從這個源裏下載，但Go不太方便，可使用vender將項目依賴的特定版本的代碼管理起來，可是會碰到被牆致使沒法下載的問題，目前的方式是將項目的依賴提取到一個公共代碼庫中，而後將公共代碼庫放到GOPATH中，若是有一些依賴不適合放入公共代碼庫，則提交到項目根目錄下的vendor中。

容器化編排（持續部署）

優先級：高

將應用使用Docker容器化，同時結合容器註冊表如Nexus、AWS ECR，容器編排工具如Rancher、K8S，則能夠實現應用的自動部署、動態伸縮，解放須要無數次的SCP命令。

團隊協做的紀律

優先級：中

• 提交規範。根據分支策略擬定提交規範，主要是小步屢次提交、提交信息要全面。
• 快速反饋。在任何工做的過程當中，若是以爲哪裏不過高效或者有問題，須要及時提出反饋共同優化現狀，被動收集反饋。
• 長期反饋。按期召集團隊成員舉辦retro，主動收集改進意見。
• 高優先級修復問題。一旦流水線或監控或日誌有異常，須要及時通知相關人員修復。

監控日誌規範化（持續運維）

優先級：中

監控：對於應用、數據庫、虛擬機都應當有一套監控方式，一旦某個運行節點出現異常則須要經過一些方式通知相關人員

日誌：將全部應用的日誌在容器內是收集，並上傳到一個日誌中心，並提供方便的查詢工具便於所有人員查詢

構建過程敏捷化（項目管理）

優先級：中（長期、穿插）

前置條件：

• 創建需求管理、文檔中心，推薦TAPD。

將構建的過程使用看板、迭代的方式管理起來，將實施的計劃與進展展現在看板上，當作開發項目同樣構建DevOps體系

在構建的過程當中，開發、部署步驟、系統架構的文檔化也是必不可少的一環，讓往後其餘同事可以接收DevOps體系和已有的系統架構。文檔化是穿插在各個地方的，每當完成一個任務就應當抽點時間補充一下文檔。

部署結果可視化

優先級：低

• 流水線可視化。流水線構建完成後，將全部流水線的狀態用可視化工具與機器在團隊內部展示出來。
• 運維面板可視化。在測試、生產環境部署完成且監控系統到位以後，將運維面板經過可視化工具展示出來，能夠實時觀察當前系統運行狀態。
• DevOps構建過程可視化。使用看板的方式將DevOps體系構建過程管理起來，先維護好TAPD電子看板，須要的話再加上物理看板。看板的資料能夠查看這裏

落地計劃

以上的實踐能夠說是須要落地的具體事情，把這些事情落地成功也須要一些方法。

遵循漸進式的實施順序：

1. 以任意一個項目爲例，將整個DevOps體系實踐根據優先級落實其中，當作一個示例規範化整個體系
2. 將已有的混亂開發部署方式以第一個項目爲例逐步遷移到咱們搭建的架構中來
3. 基本完成以後回過頭來從新審視一遍已有的體系，繼續改進

在實施的過程當中的建議：

1. 使用看板與迭代開發的方式將咱們的實施任務分配清楚，計劃制定成熟
2. 在過程當中將DevOps體系當前構建進展同步給全部人，將全部人的意識規範起來
3. 讓你的老大與團隊其餘成員意識到構建DevOps體系的必要性，爲長期發展作好鋪墊
4. 整個過程當中最大的難點多是已有的體系也比較龐大與混亂致使遷移難度大從而須要大量時間，因此必要的時候向你的老大申請更多時間與人員來

參考

myslide.cn/slides/1218
blog.jsjs.org/?p=40

91Code-就要編碼，關注公衆號獲取更多內容！