持續交付 (Continuous delivery)

持續交付，是把可釋出的軟體，規律地產生迭代版本，無論這個版本是否打算公開發行。

規律地產生迭代版本可以讓你更方便地：

• 加入改善項目
• 修正臭蟲
• 測試你的最終產品是否滿足期待

如果你的軟體還沒完成到可以真正使用，那麼這軟體不會產生任何實際價值。可以把它想成是堆積的庫存－而堆積庫存是浪費的。

Lean software development philosophy (精實軟體開發原則)告訴我們：

測試軟體的所有迭代版本，無論是透過公開的使用者測試或是自動化測試（使用其他的軟體來進行測試）。

佈署

在自動化部署流程之前，你必須充分理解其中的運作機制。如此一來，當我們把程式從 版本控制系統 放到已公開的正式環境時，如果發生任何問題就能在早期進行處理。

自動化佈署也表示，會自動進行程式碼的測試，工程師得以去修正找出的所有錯誤，所以可以 更頻繁地釋出版本 ，降低風險，讓佈署變成一件簡單的芝麻小事。

不用預先規劃遠期的正式釋出版本時程。沒有人能確定在六個月的期限內能做出什麼東西。

簡化發佈計劃 – 確保這項計畫有足夠的彈性，有任何功能或更新時，都可以隨時進行部署。如果有個功能(feature)無法安排進某次釋出版本，可以很容易地把這個功能改為安排在明天或下週，而不是6個月或更久；不應該因為下次釋出排程已滿，而需要更久時間才能釋出。

另一個優點是，如果軟體所使用的程式庫或框架有安全性修正時，可以馬上套用。我們可以很快地做些調整，然後看著這個版本更新，自動地通過佈署流程中的每個步驟，而不用擔心會弄壞什麼東西。

佈署流程

佈署流程，就是從開發者寫好程式碼，一直到佈署至正式環境之間的過程。

從頭到尾了解你的部署流程。了解其中的運作機制以及各個元素如何一起運作，相關的項目有：

• 系統配置管理 （如何在不同環境上，維持產品性能和功能的一致性）
• 自動化編譯、佈署、測試、釋出的過程

佈署流程有 4 個階段：

• 提交階段
• 共用的測試環境
• 特別測試環境
• 正式環境

提交階段

當開發人員提交程式到 版本控管系統 （儲存所有程式碼的地方，包括以前的版本），會自動對最新版本的程式執行 一系列的測試。任何可以快速修正、易於辨別的缺陷，如 編譯錯誤 或 單元測試失敗會在這個階段被發現。如果測試都通過了，這些程式碼就會進到下一階段，之後會評估是否要發佈到正式環境。

共用測試環境

把程式碼放到共用的 測試 (沙盒環境 sandbox)。這是程式被佈署和執行的第一個環境。這也是可以讓團隊中所有人可以用肉眼檢查 程式品質 的第一個階段。

讓測試環境盡可能地跟正式環境相同。舉例來說，如果正式環境使用的是 Postgres 資料庫，測試環境也應該使用 Postgres，而不是其他的資料庫像是 MySQL 或 SQLite。

主要目的是找到程式碼中的任何缺陷。如果發現了缺陷，則在此階段擋下這版本的程式碼。如果在測試環境中通關了，就可以佈署到特別測試環境。

特別測試環境

有時可能需要針對一些特別需求進行額外的測試，如 負載平衡測試和效能測試 load and performance testing ，滲透測試 penetration testing ，或無障礙測試 accessibility testing 。必須建立的特別測試環境數量，依每個專案的需求和狀況而有所不同。

當程式碼的品質到達一定水準，就可以把程式碼佈署到正式環境。

正式環境

如果程式碼通過以下關卡，就可以準備上線了：

• 提交階段
• 共用的測試環境
• 任何必要的特別測試

佈署到正式環境的方式，應該與佈署到其他環境的方式相同 － 使用相同的腳本程式，相同的 系統配置管理 工具，並且是相同的程式碼版本。這表示其實這不是你第一次釋出程式碼 － 程式碼已經在佈署流程的各個階段被驗證過，你只是單純執行一個已被各階段驗證過的任務而已。

譯者：
校稿：Richard
原始出處：https://www.gov.uk/service-manual/agile/continuous-delivery