以持續交付加快腳步

10 年之前，我們在 Amazon 承辦一個專案，以了解我們的團隊將想法化為高品質生產系統的速度有多快。這引致我們測量軟體輸送量，以便改進執行速度。我們發現，從程式碼簽入到生產平均花了 16 天。在 Amazon，團隊先從想法開始，接著一般會用一天半的時間撰寫程式碼，為想法賦予生命。我們會花不到一小時建立並部署新程式碼。其餘的時間將近有 14 天，我們等候團隊成員開始建立、執行部署，和執行測試。到了專案結尾，我們會建議將簽入後的程序自動化，以改善執行速度。其目標在於去除延遲，同時維護甚至改善品質。

此項建議的核心為一套增加執行速度的持續提升計劃。我們改善執行速度的決策是以「堅持最高標準」領導原則為依據。此項原則崇尚堅持不懈地維持高品標準，持續突破標竿，及交付高品質的產品、服務和程序。我們的領導原則描述 Amazon 如何經營事業、主管如何領導統御，以及我們如何在決策時始終以客戶為重。

Amazon 已建立軟體開發工具，提高軟體工程師的生產力。我們建立自己的集中託管建立系統 Brazil，在伺服器上執行一系列命令，以產生能夠部署的成品。在這階段，Brazil 並未聽取原始程式碼的變更。必須以人為方式起始建立。我們也自有部署系統 Apollo，其要求在起始部署的過程中，需有建立成品上傳進去。鑑於業界對於持續交付的興趣，我們建立自有系統 Pipelines，以將 Brazil 和 Apollo 之間的軟體交付程序加以自動化。

我們的發佈程序，包括管道和部署系統在內，必須能夠盡快識別這些缺陷，防止對客戶有所影響。我們需要確定將發佈程序設定正確，並且確定建立成品如所預期地運作。

部署的清潔：部署測試的最基本形式能確保新部署的成品能夠啟動，並能回應工作。部署後的工作流程中，我們會執行快速檢查，確保新部署的成品已經啟動並且為流量服務。例如，我們使用 AWS CodeDeploy AppSpec 檔案中的生命週期事件勾點來觸發簡單指令碼中對部署執行停止、開始和驗證。我們也會檢查確實有足夠容量能服務客戶的流量。我們也在 CodeDeploy 中建立例如最低運作狀態良好主機數等技術，以驗證始終有足夠的容量能夠服務客戶。最後，如果部署引擎能偵測到失敗，應該回復變更，使客戶發現缺陷的時間盡量縮短。

生產之前測試：Amazon 的最佳實務之一即為將單位、整合及前期生產測試加以自動化，並將這些測試加入我們的管道之中。我們堅持執行負載及安全測試，偏向將這些測試加入至我們的管道中。我們所說的單位測試是指您可能會想在建立機器上執行的所有測試，包括風格檢查、程式碼涵蓋範圍、程式碼複雜性等。我們所認為的整合測試包括所有離線測試，例如失敗注入、自動化瀏覽器測試等。討論單位和整合測試的優質文章很多，在此不多贅述。

我們的單位和整合測試旨在驗證我們的建立成品行為在運作上正確。執行的驗證越多，對客戶暴露出缺陷的風險越低。為縮短產品送入客戶手中之前所花的時間，我們嘗試在發佈程序中盡早偵測出缺陷。一般而言，這意味著若測試較小且較快，變更上有任何問題，就能更快收到回饋。

在 Amazon，我們也使用內部稱為前期生產測試的技術。前期生產環境是我們將變更部署進入生產之前，最後測試之處。一項前期生產環境測試採用系統的生產組態，以便行為完全如同生產系統。這種方式有兩大優點。首先，前期生產環境會測試生產組態，以確定服務能正確連線至所有生產資源，包括生產資料存放區。第二，會確保系統與其所依存之生產服務的 API 能夠正確互動。前期生產環境僅限由負責該項服務的團隊使用，並且從未接收出自客戶的流量。執行前期生產測試能提高我們的信心，確信相同的程式碼和組態在生產時能夠運作。

生產中驗證：我們將程式碼發佈給客戶時，不會全部一次完成。缺陷同時對所有客戶釋出的影響範圍太大。我們則是部署至儲存格 — 完全獨立的服務執行個體。我們將變更部署至第一個儲存格中的第一組客戶時，會極度地謹慎。我們只讓少數客戶看見新的變更，並且收集新程式碼是否有效的回饋。我們部署 Canary 之後，會監控服務發出的錯誤量。如果錯誤率上升，我們會自動將變更回復。例如，我們可能會等到有 3,000 個正資料點，並且無負資料點時，再繼續部署。

要是自動化測試漏失一個使用案例，複雜度就會提高。我們以結構化並且可重複的測試盡力捕捉所有錯誤，無論為自動化或手動式。然而，儘管我們盡最大努力，缺陷仍有可能溜過。為了測試我們的測試，我們將新作的變更留在生產中一段固定的時間，觀察是否有非團隊成員發現問題。我們已花了許多時間辯論是否應該讓變更直接留在生產中，或是在 Canary 部署完成之後應該等多久，再部署至部署群組的其餘部分。我們有許多團隊決定除了收集正資料點之外又再等候一段固定時間，才繼續部署例行程序的進展。管道等候的時間量，高度依存於團隊。一些團隊等候數小時，也有的等候數分鐘。影響越大、補救問題所花的時間越長，發佈程序越慢。

我們從第一個儲存格獲得信心之後，就會將新的程式碼變更向越來越多客戶公開，至完全發佈為止。如同對待 Canary 部署的方式，我們等候部署至第一個新儲存格獲得信心之後，再繼續往下一個儲存格進展。隨著我們從建立成品增添信心，在驗證程式碼變更之上所花的時間也跟著縮短。結果形成一種模式，我們容易把目的放在能夠從簽入盡快達到第一位生產客戶。不過，經過進入生產之後，我們慢慢將新程式碼發佈給客戶，隨著在部署的其餘部分時遞增速度，努力增加更多信心。

為了確定我們的生產系統能持續符合客戶的請求，我們在系統上生成綜合流量。我們希望要是服務無法正確運作，能迅速得到回饋，因此至少每分鐘執行一次綜合測試。我們之所以設計出綜合測試，是為了確保執行程序的運作狀態良好，並且所有相依性皆得到測試，這經常要求測試所有面向公眾的 API。

控制軟體發佈時機：為了控制軟體發佈的安全性，我們建立了一些機制以便控制變更在管道中移動的速度。我們使用指標、窗期和安全檢查來控制軟體發佈的時機。

可設定管道，使得根據指標變化發出警示時可禁止部署。我們普遍採用指標，對於系統的運作狀態、儲存格的運作狀態、可用區域和區域，以及能想到的一切幾乎都設有警示。我們將管道設定成為有重要指標觸發警示時會停止程式碼的部署。然而，有時候團隊需要部署修正程式，以處理系統警示。在此情況下，我們會讓團隊覆寫警示，防止變更在管道中移動。

我們的管道能指定窗期，在其中允許變更在管道中繼續前進。團隊能找到本身的窗期，限制變更到達客戶處的時機。AWS 的團隊偏好選擇有許多人可迅速回應，並能補救部署所造成的問題時發佈軟體。為實現此情形，團隊一般將窗期設定成為限於營業時間部署。Amazon 也有些團隊偏好於客戶流量小時發佈軟體。這些窗期可視需要加以覆寫。

我們也有能力根據建立成品的內容停止管道運行。例如，我們能將已知含有不良套件或有特定 Git 參考的建立成品加以封鎖。我們發現對套件所作的變更中含有效能回歸時，便曾使用這項功能。如果我們只將套件從套件儲存庫中移除，則已含有缺失套件的管道仍能將那項不良的變更部署至客戶處。

我們發現團隊相當急於擁抱自動化。我們都非常希望能為客戶建立和發佈可提高生活品質的功能，而持續交付可永續達成這個理念。我們見到自動化可去除令人心生挫折、易出錯誤和勞力密集的手動工作，繼而將時間交回給工程師。我們已經展現，持續部署對品質有正面影響。我們已經看出，自動化讓團隊能頻繁發佈，以及一次發佈一項變更，因此更容易識別回歸。

系統尚新時，測試的表面範圍通常能為大多數的團隊成員所瞭解，因此部分手動測試還易於處理。不過，隨著系統越來越複雜，團隊成員也改變，自動化的價值也提高了。我們樂意將系統自動化，以便專心為客戶提高價值，而非手動管理將變更從客戶處移除的程序。

多年來，Amazon 以向客戶發佈軟體的速度和這些發佈的安全為焦點，執行著持續提升計劃。我們並未從本人於此文章所述的全部風險檢查和測試著手。歷經一段時日，我們發明許多方式以識別和降低風險。

持續提升計劃是由組織不同層級的業務主管所執行。這允許各業務主管配合其業務所受的風險和影響，調整軟體發佈程序。我們有一些持續提升計劃是跨 Amazon 大型部門所執行，部分較小型組織的主管則執行本身的計劃。我們知道，規則總有例外。我們的系統有選擇退出機制，因此不致於拖慢需要永久或暫時豁免的團隊。最終，我們的團隊能掌控其軟體的行為，並對其軟體發佈程序的投資得當負起責任。

我們首先測量痛點在何處，予以解決，並且反覆處理。為使此項工作能夠永續，我們需要以遞增方式進行，逐漸享受提升的好處。Amazon 首次開始使用管道時，許多團隊不確定持續部署是否有效。為使團隊開始動作，我們鼓勵團隊將目前的發佈程序、手動程序等全部編碼至一個管道中。對許多團隊而言，其管道是作為發佈程序的視覺介面，而非經由發佈程序將建立成品自動推進之用。隨著他們的信心提高，便逐漸在管道中的不同階段開啟自動化，最終不再需要手動觸發管道的任何步驟。

時間快轉到現今。Amazon 現已來到團隊撰寫新程式碼時即以全自動為目標的時點。對我們而言，這是我們業務持續成長的唯一方式。