DevOps – 持續交付
如果把DevOps的能力提升比作是登山的話，持續交付必然是爲登山準備的最重要的工具包。雖然敏捷開發已經被大多數的軟件企業所接受，但敏捷的實踐必須能夠和持續交付的能力結合起來才能做到真正的敏捷。畢竟，我們所做的任何工作都是爲了實現價值交付。軟件如果不能實現交付使用，那麼它也只能是我們代碼倉庫的存儲物。
“如果只修改一行代碼，你的軟件需要多長時間部署上線？” 我們先來看一下軟件交付的基本流程：
從流程的角度來看，任何一個環節出現問題都可能導致一次失敗的上線部署。編碼質量不高、配置錯誤、測試不全面、部署考慮不周全都會造成最終的產品不可用，甚至造成巨大的經濟損失。那麼，在敏捷開發的過程中，持續交付又如何保障了價值交付？爲了解決代碼質量的問題，我們需要有充分的測試保障；爲了避免手工錯誤，我們需要儘可能的自動化。但在實際的工作中，不是建立了一條自動化的流水線就能解決所有的問題，讓敏捷過程和持續交付的實踐結合起來，才能發揮最大的價值。一般情況下，持續交付的流水線跟上述開發、測試、部署過程是基本一致的，但在流水線的每個階段都有其特殊的關注點。
一、持續交付的各個階段
1、部署流水線的前提條件
版本控制：一般情況下，我們都會將代碼存儲到版本控制中，但要實現自動化集成和部署，還需要將項目相關的所有內容都提交到版本庫中，包含測試代碼、數據庫腳本、構建腳本、相關配置信息，把項目中涉及到的基礎設施也作爲代碼來看待。
自動化構建：構建過程必須能夠用腳本運行，不需要人工在可視化界面上進行干預，才能實現完全的自動化。所以，在各個環節的工具選擇上，一定要選那些支持腳本化運行的工具。
團隊需要達成的共識：團隊成員要共同遵守一些紀律，如：小步增量提交、主幹開發、優先解決流水線失敗的問題等，這樣才能更及時的獲取反饋。當問題發生的時候，上下文是清晰的，解決問題也是最快的。
2、編碼階段
編碼階段，在完成功能的同時要保證單元測試的覆蓋率。最好是採用TDD，不僅僅是爲了完成測試的編寫，這是一種思維方式的改變，能使代碼結構更清晰、更有可測試性。
3、構建和配置階段
爲了能夠保證流水線正常運行，開發人員在提交代碼前，必須更新代碼並在本機執行構建，讓所有的測試能夠在本機通過，以防止給流水線帶來不必要的構建失敗。這也是代碼集成的第一次反饋,至少保證代碼在自己的電腦上是可以正常執行的。
代碼集成以後，流水線自動開始構建，如果遇到構建失敗，最好不要繼續提交代碼，把問題解決以後再繼續提交。對於代碼構建階段，在服務器上至少要運行自動化單元測試。爲了更嚴格的控制代碼質量，可以把findbugs等靜態掃描結果也作爲編譯失敗的條件。
4、測試階段
軟件進行初步的集成後，就可以進行相關測試了。目前的項目基本都是前後端分離或是微服務架構的。爲了更方便的開發聯調和測試，編輯後的二進制包會按步驟部署到三個環境，分別是Dev、Test和UAT。爲了驗證自動化部署的環境是否可用，在不同的環境中都可運行冒煙測試、自動化驗收測試及對部署環境的測試。
Dev環境：在開發過程中，各個子模塊可能會頻繁的的提交代碼，前端人員也需要與後臺的環境進行聯調，所以這個集成環境是給前後端開發人員聯調使用的。
Test環境：爲了保障測試過程的操作及數據不被幹擾，QA需要從製品庫中選出一個版本部署到Test環境中。這個過程可以在項目中約定由QA操作，或者通過設置權限，由專門人員負責。
UAT環境：該環境爲類生產環境，主要用於用戶驗收演示，也用於容量測試。
5、發佈階段
爲了防止手工發佈帶來的問題，發佈階段的工作也要儘可能的自動化。但這個過程考慮的問題也更復雜一些。從技術層面來講，如果在生產環境中發佈失敗，如何確保系統回滾且保障回滾後數據正確性。如果在不中斷業務的情況下進行發佈，對發佈操作的要求就更高一些。可以考慮藍綠部署、金絲雀發佈等策略。
對於每一次發佈，都需要制定發佈計劃。一般情況下，發現問題儘量能夠當時解決，儘量不要回滾。因爲回滾後，發佈時遇到的問題就無法重現了，失去了解決問題的機會。除非遇到無法解決且對功能有一定影響的問題才應該回滾。
二、流水線建設的問題
1、工具的使用和選擇
在工具的選擇上，如果不是特殊需求，使用更流行的工具能帶來更大的好處。越受歡迎的工具，功能一般更完善，遇到問題容易找到解決方法，工具的適應性也更強一些。因爲使用的羣體衆多，所以各種平臺的集成和支持也會更好一些。在項目中也曾遇到無法與客戶方平臺集成，而不得不更換工具的情況。
2、持續交付項目中的度量
在持續交付的項目中，應該注重整個團隊全局的度量指標。最重要的全局度量指標就是週期時間了。我們應該衡量團隊交付某個特性所使用的時間，或者在固定的迭代週期內能交付多少特性。
反饋是所有軟件交付流程的核心。只有縮短反饋週期才能使整個流程得到優化。如：識別流程中哪個環節造成了資源等待，或者資源分配不合理造成某些環節週期太長，以便於調配人員或者增加資源，或者通過技術手段解決一些問題。根據“霍桑效應”：“那些意識到自己被觀察的個人，具有改變自己行爲的傾向”。團隊管理過程注重反饋的時間，每個人也會有意識的縮短反饋時間。
3、循序漸進、持續改進
流水線沒有一個標準的流程，也不是一兩天時間就構建完善的。可以從簡單的流水線開始，根據項目的進展以及開發、測試和生產環境的變化不斷進行改進。所有的一切都是爲了自動化、爲了提升效率，爲了能夠快速的實現價值交付。
三、總結：
持續交付的重要實踐包含以下方面：
自動化部署
持續集成
持續測試
主幹開發
版本控制
數據管理和度量
持續交付只是DevOps能力模型中的一個重要組成部分，整體團隊的能力提升還需要注重敏捷開發的管理能力、技術運營的能力。這不僅僅是技術團隊的管理和能力的問題，甚至會對公司的文化和組織結構產生重大影響。
關注公衆號：
