軟體開發人員撰寫在自己的機器上執行的程式碼已經夠困難了。但即使完成了，從那裡到產生價值的軟體還有很長一段路要走，因為軟體只有在生產環境中才會產生價值。我對軟體交付的哲學精髓是建立軟體，讓它始終處於可以投入生產的狀態。我們稱之為持續交付，因為我們持續執行部署管線，測試此軟體是否處於可交付的狀態。

持續整合是一種軟體開發實務，團隊中的每位成員都會將他們的變更與同事的變更至少每天合併一次到程式碼庫中。每次整合都會由自動建置（包括測試）驗證，以盡快偵測整合錯誤。團隊發現這種方法可以降低交付延遲的風險、減少整合工作量，並啟用促進健康程式碼庫的實務，以快速增強新功能。

現代原始碼控制系統提供強大的工具，可以輕鬆地在原始碼中建立分支。但最終這些分支必須合併回主線，許多團隊花費過多的時間應付他們糾纏不清的分支叢林。有幾種模式可以讓團隊有效地使用分支，重點在整合多位開發人員的工作，並組織通往生產版本的途徑。貫穿始終的主題是分支應該頻繁整合，並專注於可以輕鬆部署到生產環境的健康主線。

我們提供持續交付的一小時概述。主題包括持續交付的理由、部署管線、持續整合、DevOps 和部署策略。重點是 Jez 將候選版本擬人化為希臘神話中的英雄。

機器學習應用程式在我們的產業中正變得越來越普及，然而，與更傳統的軟體（例如網路服務或行動應用程式）相比，開發、部署和持續改進它們的流程更為複雜。它們會在三個軸線上產生變化：程式碼本身、模型和資料。它們的行為通常很複雜且難以預測，而且更難測試、更難解釋，也更難改進。機器學習的持續傳遞 (CD4ML) 是將持續傳遞原則和實務帶入機器學習應用程式的學科。

整合必要的安全控制和稽核功能以滿足 DevOps 文化中的合規性需求，可以利用 CI/CD 管線自動化，但在組織擴展時會出現獨特的挑戰。了解所選擇實作的次要影響和意外後果是建構有效、安全且可擴充解決方案的關鍵。

我們軟體系統中的可觀察性一直很有價值，在雲端和微服務的時代，它變得更加重要。然而，我們新增到系統中的可觀察性往往本質上相當低階且技術性，而且似乎太常需要用各種記錄、儀器和分析架構來充斥我們的程式碼庫。本文描述了一種模式，可以清理這個混亂，並允許我們以乾淨、可測試的方式新增與業務相關的可觀察性。

功能切換（通常也稱為功能旗標）是一種強大的技術，允許團隊在不變更程式碼的情況下修改系統行為。它們屬於各種使用類別，在實作和管理切換時，考慮這種分類很重要。切換會引入複雜性。我們可以使用智慧的切換實作方式和適當的工具來管理我們的切換設定，以控制這種複雜性，但我們也應該試著限制系統中的切換數量。

傳統上，QA 專注於在軟體釋出到生產環境前進行測試，以查看是否已準備好進行此類釋出。但現代 QA 組織也越來越關注執行於生產環境中的軟體。透過分析記錄檔和其他監控工具，他們找出品質問題並強調給開發組織。此方法特別適用於使用持續交付將新版本的軟體快速且可靠地放入生產環境的組織。

2010 年在舊金山 QCon 訪問我和 Jez Humble

自動化回歸套件可以在軟體專案中發揮至關重要的作用，它既有助於減少生產中的缺陷，也對演化設計至關重要。在與開發團隊交談時，我經常聽到關於非決定論性測試的問題，即有時通過、有時失敗的測試。如果未加以控制，非決定論性測試可能會完全破壞自動化回歸套件的價值。在本文中，我概述瞭如何處理非決定論性測試。最初，隔離有助於減少它們對其他測試的損害，但您仍必須盡快修復它們。因此，我討論了非決定論性的常見原因的處理方法：缺乏隔離、非同步行為、遠端服務、時間和資源洩漏。

在此影片 (12 分鐘) 中，Mike Mason 和我討論了功能分支的危險及其替代方案。

Rake 是一種建構語言，其目的類似於 make 和 ant。與 make 和 ant 一樣，它是一種特定領域語言，與這兩個不同的是，它是一種使用 Ruby 語言編寫的內部 DSL。在本文中，我介紹了 rake，並描述了一些使用 rake 建構此網站時出現的有趣事項：相依性模型、合成任務、自訂建構常式和除錯建構指令碼。

我看到關於敏捷專案最常見的問題之一是如何處理移交給其他團隊。如果您有一個開發團隊離開並將支援移交給支援團隊，當敏捷專案往往產生比計畫驅動程序更少的說明文件時，他們該如何應對？

我和同事們強烈建議客戶的目標之一，就是完全自動化的部署程序。自動化部署有助於減少在完成軟體和實現其價值之間產生的摩擦和延誤。Dave Farley 和 Jez Humble 正在完成一本關於此主題的書 - 持續交付。它建立在許多通常與 持續整合 相關的想法之上，更朝向快速將軟體投入生產並讓它發揮作用的能力邁進。他們關於藍綠部署的部分引起了我的注意，因為這是一種未被充分利用的技術，所以我認為我可以在這裡簡要概述一下。

「抽象分支」是一種以漸進的方式對軟體系統進行大規模變更的技術，它允許你在變更仍在進行中時定期發布系統。

我多次談論過 持續整合 的優點。若要讓這種環境正常運作，你需要一個持續整合伺服器和一個原始碼控制系統。為了讓專案順利執行，你還可以使用問題追蹤器來追蹤錯誤等，以及一個 wiki 來協助擷取各種專案知識。

金絲雀發布是一種技術，透過在將變更推廣到整個基礎架構並讓所有人使用之前，先將變更緩慢推廣到一小部分使用者，以降低在生產環境中引入新軟體版本的風險。

現代應用程式伺服器的常見宣傳功能之一，就是它們在叢集中提供故障轉移。叢集化可提升應用程式的可靠性，如果你的其中一台伺服器發生故障，你還有更多伺服器可以為你的客戶提供服務。故障轉移可以增加更多可靠性，如果伺服器在互動過程中發生故障，叢集可以將該互動移至另一台伺服器。

然而，這可能會造成問題。

軟體系統通常會對執行於不同程序中的軟體進行遠端呼叫，這些軟體可能位於網路中的不同機器上。記憶體內呼叫和遠端呼叫之間的一大差異在於，遠端呼叫可能會失敗，或在達到某個逾時限制之前掛起而沒有回應。更糟的是，如果一個沒有回應的供應商上有許多呼叫者，那麼你可能會耗盡關鍵資源，導致多個系統發生連鎖故障。在他的優秀著作 Release It 中，Michael Nygard 推廣了斷路器模式，以防止這種災難性的連鎖反應。

斷路器的基本概念非常簡單。你將受保護的函數呼叫包裝在斷路器物件中，該物件會監控故障。一旦故障達到某個閾值，斷路器就會跳閘，並且對斷路器的所有後續呼叫都會傳回錯誤，而不會執行受保護的呼叫。通常，如果斷路器跳閘，你還需要某種監控警報。

自動化組態工具（例如 CFEngine、Puppet 或 Chef）允許你透過提供描述伺服器元素組態的範本，來避免 雪花伺服器。組態同步會持續套用這些規格，無論是按照定期排程，或是在其變更時，套用至伺服器的執行個體，並持續其生命週期。如果有人在工具外變更伺服器，則下次同步伺服器時，它將還原為集中指定的組態。如果需要進行某些組態變更，則會在組態規格（範本、清單或特定組態工具所稱呼的名稱）中進行變更，然後套用至基礎架構中的所有相關伺服器。

持續交付是一種軟體開發守則，您以這種方式建置軟體，以便隨時可以將軟體釋出到生產環境。

您在下列情況下執行持續交付

• 您的軟體在其整個生命週期中都可以部署
• 您的團隊優先考慮讓軟體保持可部署狀態，而非致力於新功能
• 當有人對系統進行變更時，任何人都可以隨時取得快速、自動化的回饋，了解其生產準備狀態
• 您可以依需求對軟體的任何版本執行按鈕部署，部署到任何環境

持續整合是軟體開發中一種廣泛使用的技術。在研討會中，許多開發人員會談論他們如何使用持續整合，而持續整合工具在大部分開發組織中都很常見。但是我們都知道，任何良好的技術都需要一個認證計畫，而且很幸運地，的確有一個認證計畫。這個計畫是由持續交付和 devops 領域的頂尖專家之一所開發，以管理快速著稱，但其結果卻非常有見解。雖然它已經相當成熟，但它的知名度並不如預期，因此作為該技術的愛好者，我認為與我的讀者分享這個認證計畫非常重要。您準備好接受持續整合認證了嗎？而您將如何應對考試揭露的驚人真相？

暗黑啟動功能是指採用新的或已變更的後端行為，並從現有使用者呼叫它，而使用者無法得知它已被呼叫。這麼做是為了在公開宣布新功能之前，評估對系統的額外負載和效能影響。

以下是最近我發現的一個有趣的對比。兩個規模相似的企業應用程式專案（約 100 KLOC），環境類似（Java 和 .NET）。一個可以在一小時內完成完整的建置和測試，另一個則需要 2-3 分鐘。

自動化建置和測試環境的挑戰之一是，您希望建置速度快，以便可以快速取得回饋，但全面測試需要花費很長時間才能執行。部署管道是一種透過將建置分為多個階段來處理此問題的方法。每個階段提供越來越高的信心，通常需要花費額外的時間。早期階段可以找出大多數問題，提供更快的回饋，而後續階段則提供較慢且更深入的探查。部署管道是 持續交付 的核心部分。

敏捷軟體開發已打破需求分析、測試和開發之間的一些隔閡。部署、運作和維護是其他活動，與軟體開發流程的其餘部分也遭受類似的隔離。DevOps 運動旨在消除這些隔閡，並鼓勵開發和運作之間的協作。

回歸錯誤是軟體功能中新出現的錯誤，這些功能已經存在一段時間了。在追蹤這些錯誤時，通常有價值的是找出軟體中的哪個變更導致它們出現。查看該變更可以提供有關錯誤位置和如何消除錯誤的寶貴線索。對於這種調查形式還沒有廣為人知的術語，但我稱之為差異除錯。

功能分支是一種原始碼分支模式，開發人員在開始開發新功能時會開啟一個分支。她會在此分支上完成所有功能開發，並在功能完成時將變更與團隊其他成員整合。

支持 功能分支 最常見的論點之一是，它提供了一種機制，可以處理需要比單一版本週期更長時間的待處理功能。假設您每兩週發佈一次產品，但需要建置一個需要三個月才能完成的功能。您如何使用持續整合讓所有人繼續處理主線，而不會在您的版本中揭露一個半實作的功能？我們經常遇到這個問題，而功能標記是一個處理它的便利工具。

我最喜歡的一句精闢言論是：如果感到痛，就更常去做。這句話表面上看起來很荒謬，但深入探究後，會發現一些有價值的意義

自動化組態工具（例如 CFEngine、Puppet 或 Chef）讓您可以指定伺服器的組態方式，並使新舊機器符合規定。這有助於避免脆弱的 雪花伺服器 問題。此類工具可以建立 鳳凰伺服器，可以隨意拆除和重建。不可變伺服器是這種方法的合乎邏輯的結論，伺服器一旦部署，就永遠不會修改，只會用新的更新實例取代。

與任何職業一樣，軟體開發也有一些經常被遺忘的活動，這些活動通常被忽略，但習慣在最不恰當的時機反撲。其中之一就是資料遷移。

基礎架構即程式碼是一種透過原始碼定義運算和網路基礎架構的方法，然後可以像任何軟體系統一樣處理。此類程式碼可以保存在原始碼控制中，以允許稽核和 可重製建置，受測試實務約束，並完全遵守 持續交付 的規範。這是一種在過去十年中用於處理不斷成長的 雲端運算 平台的方法，並將成為未來處理運算基礎架構的主要方式。

如果軟體開發團隊能盡可能頻繁地整合其工作，他們會發現生活可以輕鬆許多。他們也發現頻繁地發佈到生產環境很有價值。但團隊不希望向使用者公開半開發的功能。應對這種緊張局勢的一個有用技巧是建立所有後端程式碼，進行整合，但不要建立使用者介面。可以整合和測試功能，但使用者介面會保留到最後，直到像拱心石一樣，將其新增以完成功能，並向使用者揭示。

我是 持續整合 的忠實愛好者，這是一個相對簡單的實務，能對大多數開發團隊產生極大的影響。然而，就像大多數實務一樣，它有其缺點^H^H^H^H^H 改進的機會。Paul Duvall，這方面的 即將成為標準的書籍 作者，指出 最近的其中一項。如果提交建置中斷，整個團隊都會受到影響，並可能在修復之前減慢進度。

有一天，我幻想著為營運啟動一項認證服務。認證評估將包括我和一位同事出現在企業資料中心，並使用棒球棒、電鋸和水槍設定關鍵生產伺服器。評估將根據營運團隊讓所有應用程式重新啟動並執行的時間來進行。

Pull Request 是由 github 推廣的一種機制，用於協助合併工作，特別是在開源專案的背景下。貢獻者在中央儲存庫的 fork（複製）中處理他們的貢獻。完成貢獻後，他們會建立一個 pull request，以通知中央儲存庫的所有者，他們的作品已準備好合併到主線。在接受請求之前，工具支援並鼓勵對貢獻進行程式碼檢閱。Pull request 已廣泛用於軟體開發，但批評者擔心整合摩擦的增加可能會阻礙持續整合。

當人們想到程式碼檢閱時，他們通常會想到開發團隊工作流程中的一個明確步驟。現在，在 Pull Request 上執行的整合前檢閱是最常見的程式碼檢閱機制，以至於許多人愚蠢地認為不使用 pull request 會消除所有進行程式碼檢閱的機會。如此狹隘的程式碼檢閱觀點不僅忽視了許多明確的檢閱機制，更重要的是忽視了可能是最強大的程式碼檢閱技術 - 由整個團隊進行的持續精進。

持續整合 愛好者普遍的假設之一是建置應該是可重製的。我們的用意是，在任何時候，您都應該能夠採用您正在處理的系統的較舊版本，並以與當時完全相同的方式從原始碼建置它。

自我測試程式碼是我在 重構 中用來指稱與功能性軟體結合撰寫全面自動化測試的實務。如果執行得當，這將允許你呼叫執行測試的單一指令，而你可以確信這些測試將找出隱藏在程式碼中的任何錯誤。

聽過我和同事討論 功能分支 的人知道我們不太喜歡這種模式。我們反對的一個重要部分是觀察到分支很容易，但合併很難。我們時不時聽到的論點是，現代 版本控制工具 讓合併變得足夠容易，因此功能分支是值得的。

讓生產伺服器持續執行可能是一件很繁瑣的事情。你必須確保作業系統和任何其他依賴的軟體都正確修補，以使其保持最新。託管應用程式需要定期升級。通常需要變更組態來調整環境，使其能有效率地執行並與其他系統正確通訊。這需要一些命令列呼叫、在 GUI 畫面之間跳轉以及編輯文字檔的組合。

結果是一個獨特的雪花，這對滑雪勝地來說很好，但對資料中心來說很糟。

DevOps 報告現況是一份年度報告，使用調查資料的統計分析來確定軟體交付組織的有效實務。其主要作者是 Nicole Forsgren、Jez Humble 和 Gene Kim。

合成監控（也稱為語意監控）會定期針對執行中的生產系統執行應用程式自動化測試的子集。結果會推送到監控服務中，該服務會在發生故障時觸發警示。此技術結合了自動化測試和監控，以偵測生產中的業務需求失敗。

當人們談論 極限程式設計 時，他們通常會專注於其適應性規劃風格或其演化式設計方法等事項。一個小但日益增長的趨勢特別引起我的興趣，那就是極限程式設計專案的缺陷率很低，我的意思是每月不到一個生產錯誤。