持續整合

在我軟體產業生涯的早期，軟體專案中最尷尬和緊張的時刻之一就是整合。個別運作良好的模組被組合在一起，而整體通常會以令人抓狂且難以找出原因的方式失敗。然而在過去幾年，整合已在很大程度上不再是專案的痛苦來源，並逐漸減少到變成非事件。

這種轉變的精髓在於更頻繁地整合的實務。在某個時間點，每日建置被視為一個雄心勃勃的目標。我現在交談過的大多數專案每天整合多次。奇怪的是，當你遇到一項痛苦的活動時，一個好的建議是更頻繁地執行它。

持續整合的有趣之處之一是人們對其影響感到驚訝的頻率。我們經常發現人們將其視為邊際效益而予以忽視，但它可以為專案帶來完全不同的感覺。能見度大幅提升，因為問題被偵測得更快。由於在引入錯誤和發現錯誤之間的時間較短，因此錯誤更容易找出，因為你可以輕鬆查看已變更的內容以協助你找出來源。搭配決心堅定的測試計畫，這可以大幅減少錯誤。因此，開發人員花在除錯的時間減少，花在新增功能的時間增加，並確信他們建立在穩固的基礎上。

當然，光說你應該更頻繁地整合是不夠的。在這句簡單的口號背後是一堆原則和實務，可以讓持續整合成為現實。你可以在書籍和網路上找到許多這方面的建議（我很榮幸能為此內容做出貢獻），但你必須自己去挖掘。

因此，我很高興看到 Paul 已將這些資訊彙整成一本有系統的書籍，這是一本手冊，供那些想要彙整此最佳實務的人使用。就像任何簡單的實務一樣，魔鬼藏在細節中。在過去幾年，我們已學到許多關於這些細節以及如何處理這些細節的知識。這本書彙整了這些課程，以提供穩固的持續整合基礎，就像持續整合對軟體開發所做的貢獻一樣。