持續交付

2013 年 5 月 30 日

持續交付是一種軟體開發紀律,您以一種方式建置軟體,讓軟體隨時可以發布到生產環境。

當您:[1]

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

您可以透過持續整合開發團隊完成的軟體、建置可執行檔,以及對這些可執行檔執行自動化測試來偵測問題,來達成持續交付。此外,您會將可執行檔推送到越來越接近生產環境的環境中,以確保軟體可以在生產環境中運作。為此,您會使用部署管道

關鍵測試是業務贊助商可以要求軟體的目前開發版本可以在任何時候部署到生產環境 - 而且不會有人感到驚訝,更不用說恐慌了。

要達成持續交付,您需要

  • 參與交付的所有人之間緊密合作的工作關係(通常稱為DevOps 文化[2])。
  • 使用部署管道自動化交付流程中所有可能的部分

持續交付有時會與持續部署混淆。持續部署表示每個變更都會通過管道,並自動放入生產環境中,每天會產生許多生產部署。持續交付僅表示您可以進行頻繁的部署,但可能會選擇不這樣做,通常是因為企業偏好較慢的部署速度。為了進行持續部署,您必須進行持續交付。

Jez HumbleDave Farley 所著的書是此主題的基礎書籍

持續整合 通常是指在開發環境中整合、建置和測試程式碼。持續交付建立在這個基礎上,處理生產部署所需的最後階段。

持續交付的主要好處是

  • 降低部署風險:由於您部署的變更較小,因此出錯的機率較低,且如果出現問題,也更容易修正。
  • 可信進度:許多人透過追蹤已完成的工作來追蹤進度。如果「已完成」表示「開發人員宣告已完成」,那麼可信度遠低於已部署到生產(或類似生產)環境。
  • 使用者回饋:任何軟體專案最大的風險是您最終建置出沒有用的東西。您越早、越頻繁地讓實際使用者看到工作中的軟體,您就能越快取得回饋,找出它的實際價值(特別是如果您使用 觀察到的需求)。

使用者回饋需要您進行持續部署。如果您想要這樣做,但不想讓所有使用者取得新軟體,您可以部署到使用者子集。在我們最近的一個專案中,某零售商先將其新的線上系統部署到其員工,然後部署到受邀的一組高級客戶,最後才部署到所有客戶。

進一步閱讀

有關更多資訊,最佳的線上來源是 Jez Humble 的 持續交付 頁面。(特別是 Jez 解釋了為什麼 他和 Dave Farley 選擇了持續交付這個名稱,並將其與持續部署做對比。)有關更多詳細資訊,您應該前往 這本書。我也在我的 指南頁面 上列出了一些資源。

致謝

Jez Humble 提供了此頁面的詳細說明。

備註

1: 這些指標是由 Thoughtworks 的持續交付工作小組開發的

2: 儘管名稱為「devops」,但這應該擴展到開發人員和作業人員以外,包括測試人員、資料庫團隊以及將軟體投入生產所需的任何其他人。

於 2014 年 8 月 12 日更新,新增了有關好處和部署到使用者子集的文字。