發佈軟體（Releasing software）

規律發佈以降低風險

不斷地改善線上服務意即對基礎軟體發佈更新您更新的頻率將影響您如何設計、製造應用程式，還會帶出許多本指引希望能解決的挑戰

在您產品的開發階段，盡早考量您要如何發佈更新到正在運行的應用程式。因為這關係到軟體如何開發及測試，還有您的產品會如何地被支援。

能夠根據需求發佈軟體是重要的。六個月或更長的發佈週期是危險的。不但新功能難見天日，已知的問題也得在嚴格的發佈日程內修復。

區分下列兩者是重要的：

您的應用程式應隨時處於可被發佈的狀態，意即需要時可快速地修改。舉例來說，運行 GOV.UK 的軟體平均每天修改 5 次。

要能做到這一點，您必須考慮：

雖然你需要一些工具 (可能包括商業工具) 來幫助你快速地發佈，但不要討論應該使用或採購甚麼工具。而是根據服務和產品團隊的需要進行討論。

在某些組織，人們害怕新應用程式的發佈或軟體的新版本。許多網站 (特別是大型傳統組織中的大型應用程式) 並不常更新。許多網站有固定的發佈日程，例如：6 個月左右發佈一次。這意味著將許多改變打包進一次的發佈中，這樣做至少有兩點壞處：

雖然一項軟體的改善只花了數天就完成，但人們卻可能要等待數週或是數個月的正式發佈後才能使用到它。這個複雜性意味著有許多歧路是軟體發佈時可能會誤入的。

複雜性、風險、以及不頻繁發佈等因子互相結合，使所有因子都參與了發佈這項壓力事件。難怪大多數人都不喜歡軟體發佈日！

軟體發佈帶有風險，因此試著將風險最小化是個好主意。GDS 執行此舉有許多方法，而其好處如下：

除了可降低風險外，提早和經常發佈也能幫助產品快速改善，因為這可以將快速實驗與迭代的障礙移除。

最後，考慮系統的以下兩項措施：

傳統的方法涉及盡力去減低故障發生的間隔時間，希望改善整個系統的品質。

但是，問題總是會出現在某個時刻！花精力在減少修正錯誤所花費的時間往往更具成本效益，也改善了整個系統的正常運作時間。