持續交付

90 年代後期，我拜訪了 Kent Beck，當時他在瑞士為一家保險公司工作。他向我展示了他的專案，而他這個高度紀律團隊的一個有趣面向，就是他們每晚都會將軟體部署到生產環境。這種定期部署為他們帶來了許多優點：編寫的軟體不會在使用前白白等待，他們可以快速回應問題和機會，而快速的週轉也讓他們與業務客戶和最終客戶之間的關係更加緊密。

在過去十年，我在 Thoughtworks 工作，而我們專案的共同主題是縮短構想和可用軟體之間的週期時間。我看到許多專案故事，而它們幾乎都涉及到決心縮短該週期。雖然我們通常不會每天將成果交付到生產環境，但現在常見到團隊進行兩週一次的發布。

Dave 和 Jez 一直參與這項變革，積極參與建立頻繁、可靠交付文化的專案。他們和我們的同事已經讓那些每年掙扎著部署一次軟體的組織，進入持續交付的世界，在這個世界中，發布成為例行公事。

這種方法的基礎，至少對開發團隊來說，是持續整合 (CI)。CI 讓開發團隊彼此同步，消除了因整合問題而產生的延遲。幾年前，Paul Duvall 在這個系列中撰寫了有關 CI 的書籍。但 CI 只是第一步。已成功整合到主線程式碼串流的軟體，仍然不是在生產環境中執行其工作的軟體。Dave 和 Jez 的書從 CI 開始，處理「最後一哩路」，描述如何建置將整合程式碼轉換為生產軟體的部署管線。

這種交付思維在軟體開發中早已被遺忘在角落，掉進開發人員和營運團隊之間的洞裡。因此，本書中的技術建立在讓這些團隊齊聚一堂，這一點也不令人意外，是新興且日益壯大的「DevOps」運動的先驅。這個流程也包含測試人員，因為測試是確保版本無錯誤發布的關鍵元素。貫穿始終的是高度自動化，因此可以快速且無誤地完成工作。

讓這一切運作需要付出努力，但好處深遠。漫長、高強度的版本發布將成為過去。軟體客戶會看到想法快速轉變為他們每天都能使用的運作程式碼。也許最重要的是，我們消除了軟體開發中最大的壓力來源之一。沒有人喜歡在緊張的週末，試圖在星期一開始之前發布系統升級。

對我來說，一本書可以告訴你如何頻繁且無壓力地交付軟體，這是一本非讀不可的書。為了你的團隊，我希望你同意。