1 辨析敏捷/持續集成/持續交付/DevOps

2 持續集成

2.1 為何會有持續集成？

敏捷開發解決了單體應用的開發和每日構建的問題，

而單體應用拆分成微服務，就需要有一套方案來組裝這些微服務，使其成為可協作運行的微服務架構，該方案就是持續集成，

• 持續集成強調開發人員提交新代碼后，立刻進行構建、（單元）測驗，根據測驗結果，可確定新代碼和原有代碼是否正確集成在一起，
  

2.2 持續集成的定義

持續交付的鼻祖Martin Fowler提出：持續集成(Continous Integration)是一種軟體開發實踐，幫助團隊成員頻繁集成他們的作業，通常每個專案每天至少集成一次，從而每天有可測驗的版本，
每次集成使用自動化構建(含測驗)來實作打包和測驗，快速驗證問題，許多團隊發現持續集成顯著地降低了集成遇到的錯誤，使團隊能夠更加迅速地開發軟體，

2.3 為何需要持續集成

就如同Git是為了把代碼集成在一起管理，持續構建就是把功能集成在一起，保證編譯不出錯，
類似的還有自動化測驗保證一個模塊的功能集成在一起能夠正確作業，
聯調測驗環境則能將不同模塊之間集成在一起，在一個類生產的環境中進行測驗，

2.4 持續集成流水線的設計

3 持續部署

3.1 傳統部署的缺陷

• 傳統部署部署方式嚴重依賴手工部署，人力成本高
• 生產環境依賴手工配置進行變更，非常繁瑣
• 熬夜加班進行上線部署，效率很低

3.2 持續部署的定義

首先明確概念，軟體部署：將軟體按期望狀態部署到目標機器的期望路徑，

持續部署：自動化的將一或多個軟體盡可能快的、穩定的、可重復的聯合部署到目標機器，以便軟體功能的驗證和實際運行，
可能是在云環境中自動部署、app升級(如手機上的應用程式)、更新網站或只更新可用版本串列，

• 持續部署是在持續交付基礎上，將部署到生產環境這一程序自動化，

3.3 持續部署的基本要素

• 自動化部署 - ansible
• 應用與配置分離，一次構建，多處運行 - Spring Cloud Config
• 提供應用健康監測的介面 - Spring Cloud Actuator

3.4 常見自動化部署方法

其中的vault專門用于存盤一些加密資訊，比如用戶密碼

3.5 測驗部署效果

藍綠部署（Blue-Green Deployment）

一種應用發布模式，可將用戶流量從先前版本的應用或微服務逐漸轉移到幾乎相同的新版本中（兩者均保持在生產環境中運行），

該種部署軟體的方法中，維護兩個相同的主機環境

• 藍色
  舊版本的生產環境
• 綠色
  新版本的預發布環境

一旦生產流量從藍色完全轉移到綠色，藍色就可在回滾或退出生產的情況下保持待機，也可更新成為下次更新的模板，

自動化部署面臨的挑戰之一是轉換本身，將軟體從測驗的最后階段轉移到實際生產中，通常，您需要快速執行此操作，以最大程度減少停機時間，藍綠部署方法通過確保擁有兩個盡可能相同的生產環境來做到這一點，
在任何時候，其中一個（例如藍色）都處于活動狀態，準備新版本的軟體時，在綠色環境中進行最后的測驗階段，一旦軟體在綠色環境中運行，就可以切換路由器，以便所有傳入請求都進入綠色環境-藍色的請求現在處于空閑狀態，

藍綠部署還提供了快速回滾的方法-如果出現任何問題，將路由切換回藍色環境，
在綠色環境處于活動狀態時，仍然存在處理丟失的事務的問題，你可能能夠以在綠色環境處于活動狀態時將藍色環境作為備份的方式向這兩個環境提供交易，或者，您可以在切換前將應用程式置于只讀模式，以只讀模式運行一段時間，然后將其切換為讀寫模式，這可能足以清除許多未解決的問題，
兩種環境必須不同，但要盡可能相同，在某些情況下，它們可以是不同的硬體，也可以是在相同（或不同）硬體上運行的不同虛擬機，它們也可以是一個單獨的操作環境，分為兩個區域，兩個區域具有單獨的IP地址，
將綠色環境投入使用并對它的穩定性感到滿意之后，就可以將藍色環境用作過渡環境，以進行下一個部署的最后測驗步驟，準備好發布下一個版本時，你從綠色切換為藍色的方式與之前從藍色切換為綠色的方式相同，這樣，綠色和藍色環境便會定期在實時上一個版本（用于回滾）和下一個新版本之間進行回圈，
這種方法的一個優點是，它與獲得熱備份作業所需的基本機制相同，因此，這使您可以在每個版本上測驗災難恢復程序， （我希望你發布的時間比災難多得多，）基本思想是要在兩個易于切換的環境之間進行切換，有很多方法可以更改細節，一個專案通過跳動Web服務器而不是在路由器上作業來進行切換，另一種變化是使用相同的資料庫，從而為Web和域層設定了藍綠色的開關，使用這種技術，資料庫通常可能是一個挑戰，尤其是當您需要更改架構以支持軟體的新版本時，技巧是將架構更改的部署與應用程式升級分開，因此，首先應用資料庫重構來更改架構以支持應用程式的新舊版本，進行部署，檢查一切是否正常，以便您有一個回滾點，然后部署該應用程式的新版本， （并且在升級失敗后，洗掉對舊版本的資料庫支持，）

該技術已經存在了很長時間了，但是Martin Fowler并不認為它應該經常使用， Daniel Terhorst-North和Jez Humble的一些模糊組合提出了這個名稱，

這種持續部署模式原本存在不足之處，并非所有環境都具有相同的正常運行時間要求或正確執行 CI/CD 流程（如藍綠部署）所需的資源，但是，隨著企業加大對數字化轉型的支持，許多應用開始支持這種，

模型圖

在這些實體的前面是調度系統，它們充當產品或應用程式的客戶“網關”，通過將調度系統指向藍色或綠色實體,可以將客戶流量引流到期望的部署環境，通過這種方式，切換指向哪個部署實體(藍色或綠色)對用戶來說是快速簡單而透明的，

金絲雀部署（灰度發布）

一部分客戶流量被重新引流到新的版本部署中，例如，新版本的搜索服務可與當前服務的生產版本一起部署，
然后，可將10%的搜索查詢引流到新版本，以在生產環境中對其進行測驗，

如果服務那些流量的新版本沒問題，那么可能會有更多流量會被逐漸引流過去，如果仍然沒有問題出現，那么隨時間推移，可對新版本增量部署，直到100%的流量都調度到新版本，

模型圖

暗發布（DarkLaunching）

也叫功能開關，指軟體特性在正式發布之前，先將其第一個版本部署到生產環境，通過應用“開關”技術，使用戶在無感的情況下應用新特性的功能，軟體提供商通過收集用戶的實際操作記錄來獲得針對這個新特性的反饋資料，
當然，發布新特性，使用戶無感還是比較難做到的，新特性所針對軟體的改變通常不體現在用戶經常使用的界面按鈕的調整，更多的是后臺交易邏輯或演算法層面的調整，

對于可能需要輕松關掉的新功能(若發現有問題)，開發人員可添加功能開關(feature toggles)，這是代碼中的if-then軟體功能開關，僅在設定資料值時才激活新代碼，

• 此資料值可以是全可訪問的位置，部署的應用程式將檢查該位置是否應執行新代碼，如果設定了資料值，則執行代碼；如果沒有，則不執行，
• 這為開發人員提供了一個遠程“終止開關”，以便在部署到生產環境后發現問題時關閉新功能，
  

案例

某互聯網公司重新開發了一個在線新聞推薦演算法，希望能夠為其用戶推薦更多和更好的新聞內容，但是，由于此演算法相對于以前演算法的復雜度較高，提供演算法的公司需要搜集該演算法的執行效果，基于這種需求，我們就可以應用暗部署的方法，我們可以為這個演算法配置一個開關，并將其部署到生產環境中，當針對這個演算法的開關打開時，用戶的訪問流浪就會觸發這個新演算法的執行，通常用戶并不知道其此次訪問所呼叫的演算法的新舊，如果這個演算法在大規模用戶并發情況下的性能不好，我們就可以馬上關閉這個演算法所對應的開關，讓用戶使用原來的演算法，

參考

• https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/
• https://tech.youzan.com/gray-deloyments-and-blue-green-deployments-practices-in-youzan/
• http://stormluke.me/deploy-not-equal-release-part-one/
• https://martinfowler.com/bliki/BlueGreenDeployment.html