GDS Digital Service Manual 中文翻譯網站 (beta)
by HPX-GOV 英國政府數位服務研究小組 GDS Study Group
Home » 英國政府數位服務設計手冊 » 敏捷方法 (Agile) » 持續交付 (Continuous delivery)

持續交付 (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

請留言

你的email信箱不會被發布出來. Required fields are marked *

*