引言

DevOps 是一套實踐方法，在保證高質量的前提下縮短系統變更從提交到部署至生產環境的時間，其中持續集成和持續交付是 DevOps 里面非常重要的一環。本文講述了達到自動化持續交付需要做的準備工作，流水線構建方法和最佳實踐。

關于持續交付

持續交付是一組能夠幫助軟件開發團隊極大的提高其軟件交付的速度和質量的模式和最佳實踐組成。

image.png

不同于低頻率發布相對較大的版本，實施持續交付的團隊希望比通常更頻繁地將更小批量的變更投入生產， 例如每周，每天或一天之內就能夠發布多個版本。

這種軟件交付方式可以帶來許多的好處，就像市場領導者 Facebook，LinkedIn 和 Twitter 那樣，他們頻繁地，以迭代方式發布軟件，并取得了巨大的成功。 然而，要達到這種結果，需要對您開發和交付的方式進行一些潛在的重大變革。

持續交付的核心價值

軟件的核心價值是為軟件的使用者帶來收益，在過去我們經常聽到開發人員說這個功能已經開發完成了。 但是在持續交付中我們認為之后將特性真正的發布到用戶手上才以為則完成

image.png

終極目標

持續交付將在以下方面為您提供幫助：

• 盡可能快地交付軟件，盡可能早地將有價值的新功能運用于生產
• 提高軟件質量，系統正常運行時間和穩定性
• 降低發布風險，避免同時在測試和生產環境部署失敗
• 減少浪費，提高開發和交付過程的效率
• 使您的軟件始終處于生產就緒狀態，以便您可以隨時部署

創建一個可重復且可靠的自動化過程

為了達到目的，您首先需要有以下基礎：

• 自動化測試等開發實踐
• 軟件架構和組件設計，可幫助做更頻繁的發布，而不影響用戶，包括功能標志
• 工具如源代碼管理，持續集成，配置管理和應用發布自動化軟件
• 自動化和腳本化，使您能夠以有限的人為干預重復構建，打包，測試，部署和監控軟件
• 組織，文化和業務流程的變化，以支持持續交付

聽到持續交付這個詞，有些人的第一個擔憂就是這是否意味著軟件質量標準將會下滑，否則團隊需要走捷徑才能實現軟件的頻繁發布。

事實恰恰相反，為了支持持續交付而采取的措施和體系幾乎肯定會提高軟件發布的質量，并且在軟件版本出錯時將給予您額外的安全防護。

您的軟件仍然會經歷與現在相同的嚴格測試階段，可能包括手動質量檢查測試階段。持續交付只是讓您的軟件以最嚴格和最有效的方式在您設計的流程中流轉，從開發到最后的生產。

持續交付的關鍵構建模塊：自動化！

盡管在持續交付流程中采取手動步驟是非常有效和現實的，但自動化是加快交付步伐和縮短周期時間的關鍵。

畢竟，即使擁有再豐富資源的團隊，手工構建，打包，編譯，測試和部署軟件也是不可行的，尤其是在軟件很大或者復雜的情況下。

因此，最重要的目標應該是使開發者和生產環境之間的大部分路徑自動化。 以下是您應該專注于自動化工作的一些主要領域。

自動化構建和打包

需要實現自動化的第一件事就是將開發人員的源代碼轉換為部署就緒制品的這個過程。雖然大多數軟件開發人員使用諸如 Make，Ant，Maven，NuGet，npm 等工具來管理其構建和打包，但是許多團隊在制作好準備發布的制品之前仍需要執行一些手動步驟。

這些步驟是實現持續交付的重大障礙的代表。 例如，如果每三個月發布一次，手動構建與安裝就顯得不那么繁雜。但是，如果您希望每天或每周發布多次，那么這個任務可靠的自動化會更合適。

目標：實現單個腳本或命令，使您能夠將版本控制的源代碼轉換為單個可部署的制品。

自動化持續集成

持續集成是持續交付的基本組成部分。它涉及整合多個開發人員的代碼，并不斷編譯和測試集成的代碼庫，以便盡可能早地識別錯誤。

image.png

理想情況下，此過程將利用自動化構建，從而使您的持續集成服務器不斷地發布包含開發團隊集成工作的部署制品，每個構建的結果都是可行的發布候選。

通常，您將建立一個持續集成服務器或相關云服務（如 Jenkins，TeamCity 或 Team Foundation Server），每天可能會執行多次集成，很可能在每次提交時觸發。

第三方持續集成服務，如 DaoCloud Services，CloudBees DEV@cloud，Travis CI 或 CircleCI 可以幫助您加快您的持續集成進度。 通過外包您的持續整合平臺，您可以自由地專注于持續交付的目標，而不是管理工具和基礎架構。

目標：
1.實現持續集成過程就是持續輸出一組可用于部署的制品
2.評估基于云的持續集成產品，以加快您的持續交付進程
3.通過發布跟蹤軟件（如Jira）的集成，整合對每個構建所發生變化的詳細審計跟蹤

您的持續集成工具可能對您的持續交付工作至關重要。 例如，它可以超越構建并進入測試和部署。 因此，持續集成是您持續交付戰略的關鍵要素。

自動化測試

雖然持續交付可以（并且經常）包括由質量保證團隊執行的手動測試階段或最終用戶驗收測試，但是自動化測試幾乎肯定將是您加快交付周期并提高質量的關鍵功能。

通常，您的持續集成服務器將負責執行大多數的自動化測試，以驗證每個開發人員提交的代碼。

然而，當系統部署到測試環境中時，某些自動化測試可能需要被執行，因此您還應該盡可能多的實現自動化測試。您的自動化測試應該是詳盡的，能夠覆蓋測試應用程序的多個方面：

理想情況下，這些測試可以分布在部署流水線中，隨著流水線中的測試越來越詳細和價值越來越高，在生產環境中，這些發布候選制品看起來越來越可靠。其目標應該是盡早確定有問題的構建，以避免返工，盡快縮短周期時間和獲得反饋。

目標：
1.讓您的測試盡可能多的實現自動化
2.提供針對代碼部件和部署系統的多級抽象的良好測試覆蓋
3.在您的部署流水線中分發不同類別的測試，模擬日后的生產環境并進行更加詳細的測試，同時避免人力返工

在微服務風格的環境中，跨部署組件的集成和協同測試越來越重要。在這樣的環境中，自動化部署所有必需的應用程序的功能成為高優先級的任務。

自動化測試是您發布高質量軟件的主要防線，投資這些測試可能是昂貴的，但這一系列的自動化測試將在應用的整個生命周期內提供持續幫助。

自動化部署

軟件團隊通常需要將發布后續推送到不同部署環境進行上述討論的不同類別的測試。

例如，常見的情況是將軟件部署到測試環境進行人為的質量檢查測試，然后部署到性能測試環境，進行自動化負載測試。 如果構建通過該測試階段，則應用程序可能稍后部署到用于 UAT 或 beta 測試的獨立環境中。

理想情況下，將任意發布候選制品以及與之通信的其他系統可靠地部署到任意環境中的這個過程應盡可能實現自動化。

如果您希望按照計劃的速度持續交付，那可能需要每天或每周多次執行，因此它的工作速度和可靠性至關重要。

用自動化方式在環境之間移動軟件是作為繼續交付的團隊的主要特性之一，因此這也是繼續交付的關鍵重點。

目標：
1.能夠簡單的在任意環境中部署發布某任意特定版本
2.使用冒煙測試確保部署系統的可用性
3.加強部署過程，使其永遠不會讓環境處于斷開或部分部署狀態
4.將自助服務功能納入此過程，因此質量保證人員或業務用戶可以選擇軟件版本，并方便部署。在較大的組織中，此過程應5.包含業務規則，使特定用戶具有特定環境的部署權限
6.評估應用的版本自動化工具，以加快持續部署能力

受管理的基礎架構和云服務

在持續的交付環境中，可能希望具有更多靈活性和敏捷性來應對環境的創建和拆除，應對項目不斷變化的需求。

如果要啟動新的環境并添加到部署流水線中，而且該過程需要花費幾個月的時間去購買硬件，配置操作系統，配置中間件并將其正確部署，因此敏捷性受到了嚴重限制，您的交付能力同時也受到了限制。

利用虛擬化和基于云的產品可以幫助您。 考慮像 阿里云，騰訊云，Amazon EC2，Microsoft Azure 或 Google Cloud Platform 這樣的云端主機，您可以根據項目的要求靈活地開發新的環境和新的基礎架構。

云也可以為生產應用程序做出最佳選擇，使您在開發和生產環境中實現高度的一致性。

目標：
1.為持續交付流程提供更多靈活性，以便您可以按需伸縮您的流水線
2.在云中實施持續的交付基礎設施，能夠快速推出新環境，并在需求減少的情況下暫停或拆除這些環境

基礎架構即代碼

當配置方面不一致時候，例如當開發環境與測試不同，或當測試環境與生產不一致時，會發生非常常見的一系列生產事件，錯誤最終導致返工。

配置管理工具（如 Puppet，Chef，Ansible 或 Salt）和環境建模工具（如 Vagrant 或 Terraform）可幫助您通過將基礎架構和平臺提供版本控制代碼來避免這種情況，然后將環境自動構建成一致和可重復的狀態。

結合云和外包基礎設施，這種雞尾酒【混合模式】可以讓您輕松部署準確配置的環境，從而為您的交付速度帶來真正的提升。

Vagrant 和 Terraform 也可以為開發人員提供非常一致和可重復的開發環境，可以在自己的機器上進行虛擬化和運行。 容器是實現此目的的另一個常用選項。

這些工具都非常重要，因為環境的一致性是允許軟件以一致和可靠的方式流過流水線的巨大推動力。

目標：
1.實施配置管理化，更加全面地控制構建環境，特別是與云結合使用
2.Vagrant，Terraform和容器框架，以此為開發者提供非常一致的本地開發環境

容器技術

另一種方式，容器在持續交付準備中的多個時刻都可能會出現：無論是生產環境的首次運行，或者創建可重復本地設置的更輕量級手段，還是簡單的跟蹤技術的未來潛能。

如果您決定嘗試將應用程序容器化，請確保您已經了解了業務流程框架，如 Docker Swarm，Mesos 或 Kubernetes，這將幫助您將相關容器組定義和控制為單個版本化實體。

如果您計劃在容器上運行生產環境，請確保您選擇的業務流程框架也可用于本地開發。否則，會存在容器在開發機器上 “鏈接” 的方式與生產環境中不一致的風險。

自動的生產部署

雖然大多數軟件團隊的構建和測試都具有一定程度的自動化，但是在生產服務器上部署的實際行為仍然是典型軟件團隊最為手動的過程之一。

例如，團隊可能會將多個二進制文件推送到多個服務器上，一些手動執行的數據庫升級腳本，然后是一些手動安裝步驟來將它們連接在一起。他們通常也會執行系統啟動的手動步驟和冒煙測試。

由于這種復雜性，發布經常發生在業務工作時間之外。事實上，一些不幸的軟件團隊必須在星期天早上凌晨3點進行升級和定期維護，以免造成影響！

要實現持續交付，您需要解決這一痛苦，悠閑的編寫腳本并自動從您的生產發布過程中代替手動執行步驟，以便可以重復和一致地運行。理想情況下，您需要做到能夠在機器還在使用的業務時間內完成以上過程。這可能會對系統的體系結構產生重大影響。

為了實現使用中的系統能夠每天生產部署多次，要確保該過程也經過了測試和加固，以免由于部署失敗而使生產應用程序處于斷開狀態。

目標：
1.完全自動化生產部署過程，使其可以從單個命令或腳本執行
2.在生產系統生效的同時，可以部署軟件的下一個版本，并切換到新版本，而不會降低服務質量
3.能夠使用完全相同的部署到其他環境的流程來部署到生產
4.實施下面描述的最佳做法，例如金絲雀釋放，回滾和監控，以提高生產系統的穩定性

把所有東西納入版本控制版本控制

在過去通常而言我們的svn或者git當中只存在我們源代碼本身，而在持續交付過程當中我們認為任何會對軟件的行為，質量產生影響的部分都應該要做版本化的，并且這些任何部分的每一次變更都應該通過持續部署流水線的形式來進行自動化的驗證。確保任何的變更，如代碼變更，測試用例變更，環境配置變更都能得到快速的驗證，以及反饋

這些相關的“變更集”包括：基礎設施描述文件,源代碼，測試腳本，自動化測試用例，環境配置腳本，部署腳本，以及數據庫的創建，升級，以及回滾腳本等。

從上面的“變更集”也可以看出，持續交付是一個團隊所有人員和角色都應該參與的事情，并且每一個人都對軟件交付富有責任

提前并頻繁的做讓你感到痛苦的事情

“如果集成是讓你感到痛苦的，那么每一次代碼提交都應該進行集成，而且應該從項目一開始就開始這么做；如果發布軟件過程前測試是一件痛苦的事情，那么就應該從項目一開始就不斷的進行測試；如果軟件發布是一件痛苦的事情，那么每一次代碼提交在完成自動化驗收測試之后都應該進行發布，或者至少發布到類生產環境”

內建質量

在持續交付過程中持續交付流水線定義了一套標準的，可重復的軟件交付流程；同時借助大量的工具我們可以將這個流程中的機會所有事情都進行自動化。但是另外一個點就是軟件質量。

image.png

根據原則四，其實我們也可以推斷出如果對代碼進行測試是一件痛苦的事情，那么在編寫實現代碼之前我們就應該寫測試，TDD，ATDD，BDD等軟件研發實踐正是體現了這一基本原則。

內建質量是戴明提出的名言之一。越早的發現缺陷，修復它們的成本越低。

根據內建質量的原則我們可以知道在軟件交付過程中，測試并不是一個階段，所以并不應該在開發介紹之后才開始。同時測試也不應該主要是測試人員的職責，參與交付的所有人都應該對軟件的質量負責

其中測試四象限很好的闡述了為了確保軟件質量而應該做的各種類型的測試建模

image.png

Done”意味著“已發布”

在持續交付過程中認為一個特性的交付在理想狀態下應該是已經發布到用戶手中，或者至少已經向用戶進行了演示。

相應的在敏捷開發中，我們每一個迭代結束后都應該想"用戶代表"進行演示，并且在“用戶代表”試用認為是完成了之后才意味則“Done”

其中“用戶代表”可以是正在的用戶，也可以是相關的業務人員

交付過程是每個成員的責任

在現實情況下，測試部門總是抱怨研發交付的軟件質量差，運維總是抱怨軟件不夠穩定，開發總是抱怨缺陷反饋周期太長，解決問題的成本過高。

而在持續交付當中我們知道，對于交付團隊而言最終目標是確保軟件能夠交付到用戶手中，并且產生相應的價值。

而通過持續部署流水線，我們將所有參與到軟件交付中的角色都聯合成了一個整體，并且各個部分之間是能夠快速的產生反饋，促成各個成員和角色之間的交流，并且快速的解決問題

持續改進

在任何一個充滿生機的組織當中持續改進是這個組織保持活力的基本要素之一。

參與軟件交付的成員需要定期對過去一段時間內的交付工作進行回顧，去發現在這個流程當中的做的好的方面，以及做的不好的方面，并且提出解決方案。

image.png

參考文章

公眾號：道客船長 、Wise2C