軟體交付指南

持續整合是一種軟體開發做法，團隊中的每位成員都會將自己的變更與同事的變更一起合併到程式碼庫中，至少每天一次。每次整合都會透過自動建置（包括測試）進行驗證，以盡快偵測整合錯誤。團隊發現這種方法可以降低交付延遲的風險、減少整合的精力，並支援促進健康程式碼庫的做法，以便快速使用新功能進行強化。

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

持續交付是一種軟體開發規範，您以這種方式建置軟體，讓軟體可以在任何時候發布到生產環境。

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

• 您的軟體在其整個生命週期中都可以部署
• 您的團隊優先考慮讓軟體可以部署，而不是開發新功能
• 任何人都可以隨時在有人對其系統進行變更時，快速自動化地獲得其生產準備狀態的回饋
• 您可以根據需要，對軟體的任何版本進行按鈕部署，到任何環境

持續整合是軟體開發中的一種流行技術。在會議中，許多開發人員會談論他們如何使用它，而且持續整合工具在大部分的開發組織中都很常見。但是我們都知道任何體面的技術都需要一個認證計畫，而且幸運的是，確實有一個計畫存在。它是由持續交付和 devops 領域的頂尖專家之一所開發，以其執行速度極快但結果非常有見地而聞名。雖然它已經相當成熟，但它的知名度還不夠，因此作為該技術的愛好者，我認為與我的讀者分享這個認證計畫很重要。您準備好接受持續整合認證了嗎？而且您將如何應對參加考試將揭示的令人震驚的真相？

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

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

關於持續傳遞的權威書籍，其中概述了將程式碼快速且安全地導入生產環境所需的實務。關鍵方面是參與發布流程的每個人之間的協作，以及盡可能自動化該流程的許多方面。本書探討了組態管理、自動化測試和持續整合的基礎，並說明如何建置部署管線，以將整合且經過測試的程式碼上線。本書詳細說明了傳遞生態系統、管理基礎架構、環境和資料。

持續傳遞現已成為有效軟體傳遞組織的核心實務。此演講說明了持續傳遞如何運作的基本原理、部署管線的角色、持續傳遞與持續部署之間的差異，以及一些重要的要素。它也涵蓋了持續傳遞的三個主要優點：降低部署風險、可信進度和使用者回饋。

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

現代的原始碼控制系統提供強大的工具，讓在原始碼中建立分支變得容易。但最後這些分支必須合併在一起，許多團隊花費過多時間處理糾結的分支叢林。有幾種模式可以讓團隊有效地使用分支，專注於整合多位開發人員的工作，並組織通往生產發行的路徑。總體的主題是分支應該頻繁整合，並將精力集中在一個可以輕鬆部署到生產環境的健康主線上。

我和我的同事們敦促客戶達成的目標之一，就是完全自動化的部署流程。自動化部署有助於減少在軟體「完成」與實現其價值之間產生的摩擦和延遲。Dave Farley 和 Jez Humble 正在完成一本關於這個主題的書 - 持續交付。它建立在許多通常與 持續整合 相關的想法之上，更朝著能夠快速將軟體投入生產並執行某項任務的方向推進。他們關於藍綠部署的部分引起了我的注意，因為這是一種未被充分利用的技術，所以我認為我可以在這裡簡要概述一下。

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

船運/展示/詢問是一種分支策略，結合了拉取請求的功能，並具備持續運送變更的能力。變更分類為船運（合併到主線路而無需審查）、展示（開啟拉取請求進行審查，但立即合併到主線路）或詢問（在合併前開啟拉取請求進行討論）。

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

我們軟體系統中的可觀察性一直都很寶貴，在雲端和微服務的時代更是如此。然而，我們添加到系統中的可觀察性往往相當低階且技術性，而且似乎經常需要使用各種記錄、儀器和分析架構來散佈我們的程式碼庫。本文描述了一種模式，可以清除此混亂，並允許我們以乾淨、可測試的方式新增與業務相關的可觀察性。

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

我最喜歡的口號之一是：如果感到痛苦，就更頻繁地執行。它有一個令人愉快的特性，表面上看起來沒有道理，但深入探討後會產生一些有價值的意義

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

軟體開發團隊如果能盡可能頻繁地整合工作，會發現生活可以輕鬆許多。他們也發現頻繁地發布到生產環境很有價值。但是團隊不希望將半開發的功能暴露給使用者。處理這種緊張關係的一個有用技巧是建置所有後端程式碼，整合，但不要建置使用者介面。這個功能可以整合並測試，但使用者介面會保留到最後，就像拱心石一樣，加入以完成這個功能，並向使用者揭示。

軟體開發就像任何專業一樣，有許多經常被遺忘的活動，通常會被忽略，但在最不恰當的時刻養成反咬一口的習慣。其中之一就是資料遷移。

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

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

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

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

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

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

「雲端」在過去幾年已成為一個非常炒作過度的術語。炒作過度字詞的一個特徵是它們幾乎沒有定義（是的 NosqlDefinition 我在看你）。

事實證明，有一個極佳的雲端運算定義，來自無他，就是 NIST。它有一個非常簡短且易於理解的 標準文件（不，我不是在開玩笑）。

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

結果是一個獨特的雪花 - 對滑雪場來說很好，對資料中心來說很糟。

有一天，我幻想為營運啟動一個認證服務。認證評估將包含我和一位同事出現在公司資料中心，並帶著棒球棒、電鋸和水槍設定關鍵生產伺服器。評估將根據營運團隊讓所有應用程式再次啟動並執行的時間長度為依據。