1.5 候選發布版本

什么是候選發布版本（release candidate）？對于代碼的任何一次修改都有被發布出去的可能性。當你問自己“我們這次修改的版本是否應該發布出去”時，得到的答案很可能只是一次臆測的結果而已。然而，恰恰是構建、部署、測試流程能夠驗證是否可以發布這次修改后的版本。對于“是否可以發布這次修改的版本”這個問題，這一流程會不斷讓我們增強信心。我們只做很小的修改（無論是新功能，還是修復缺陷，或是提高一些性能），并且驗證我們是否有足夠高的自信把這個帶有本次修改的系統發布出去。為了進一步減少發布風險，我們希望盡可能在最短的時間內完成這個驗證過程。

盡管每次修改都可以產生一個能夠交給用戶的最終產物，但是我們應該首先對每次修改都進行適用性評估。只有這次修改沒有缺陷，而且滿足由客戶定制的驗收條件，才能夠發布它。

大多數軟件發布方法都是在其流程的最后階段才能識別出可以發布的那些版本。當說到與跟蹤（tracking）相關的工作時，這是有些意義的。在寫作本書時，Wikipedia上對開發階段的描述中將“候選發布版本”作為這一流程中的一個步驟進行了說明，如圖1-2所示。我們的觀點則稍有不同。

圖1-2 對于發布候選版本的傳統觀點

在傳統軟件開發方法中，通常以較長時間的驗證過程來確保軟件滿足質量要求并實現了全部功能需求，之后才確定能夠發布的候選版本。然而，當有全面的自動化測試，并且構建和部署也是自動化過程時，我們在項目后期就不再需要冗長且手工密集型的測試了。在這一階段應用程序的質量通常也會比較高，手工測試只是用于證實功能完備就行了。

根據我們的經驗，直到開發階段之后才做測試的話，無疑會降低應用程序的質量。最好還是在缺陷被引入時，就發現并將其解決。發現得越晚，修復的成本越高。開發人員已經不記得他們是在實現哪個功能時把缺陷引入的，而這個功能很可能已經發生了變化。直到最后才做測試，這通常意味著沒有足夠的時間真正地修復缺陷，或者只能修復其中很少的一部分缺陷。因此，我們想盡早地發現并修正這些缺陷，最好是在將其提交到代碼庫之前。

每次提交代碼都可能產生一個可發布的版本

開發人員對代碼庫的每次修改都應該是以某種方式為系統增加價值。每次代碼到版本控制系統的提交都應該是對當前所開發軟件的提高或增強。我們如何知道它的正確性呢？唯一的方法就是運行這個軟件，看它的行為是否符合我們的期望。大多數項目都將這部分工作推遲到了開發的后期。這就意味著，即使它不能工作，也只有當有人測試或使用這個軟件時才能被發現，而此時的修復成本通常會比較高。這個階段通常稱作集成階段，常常是整個開發過程中最不可預測、最不易管理的階段。由于集成這件事太痛苦了，所以團隊總是推遲集成工作。然而，集成頻率越低，集成時我們就會越痛苦。

如果在軟件開發中的某個任務令你非常痛苦，那么解決痛苦的方法只有更頻繁地去做，而不是回避。因此，我們應該頻繁做集成，事實上應該在每次提交修改后都做集成。持續集成這個實踐將頻繁集成發揮到了極至，而“持續集成”轉變了軟件開發過程。持續集成會及時檢測到任何一次破壞已有系統或者不滿足客戶驗收測試的提交。一旦發生這種情況，團隊就立刻去修復問題（這是持續集成的首要規則）。如果能夠堅持這個實踐，那么軟件會一直處于可用狀態。假如測試足夠全面，且運行測試的環境與生產環境足夠相近（甚至相同）的話，那么可以說，你的軟件一直處于可發布狀態。

我們可以把每次修改都作為一個有可能被發布的候選版本。每次將修改后的代碼提交到版本控制系統時，我們都希望它能夠通過所有的測試，產生可工作的軟件，并能夠發布到生產環境中，而這只是我們的一個假設。持續集成系統的職責就是推翻這一假設，證明某個版本并不適合部署到生產環境中。