可重現建置

熱衷於 持續整合 的愛好者普遍認為，建置應該是可重現的。我們的定義是，在任何時候，您都應該能夠取得您正在處理系統的舊版本，並以與當時完全相同的方式從原始碼建置。

在我通常用於建置流程的來源中，這並未被視為關鍵實務。我想這是因為這是一個基本假設，被認為很明顯，無需解釋。

擁有可重現建置的主要原因之一，是確保我們可以處理仍在使用的舊版本中的問題。如果我們在一年之前發布軟體給客戶，而他們現在回報了一個嚴重的錯誤，能夠重新建立該軟體以提供修正程式非常重要。

但讓我們假設一個案例，您每週都會發布軟體到一個託管環境。我們也假設您有一個穩固的 持續交付 流程，因此確信您可以透過等待下一次發布或（如果真的很緊急）進行早期發布來宣告錯誤修正。那麼您是否仍然需要可重現建置？

在您會：收到錯誤回報、在 head 上重現錯誤、在 head 上修正錯誤，然後等待或立即發布的場景中，您不需要。但有些情況下，擁有可重現建置仍然非常方便。

當您收到錯誤回報，但無法重現時會發生什麼事？您會直接宣告已修正並繼續進行嗎？我不會滿意這樣的回應。首先，我想確定我確實了解錯誤，因此我想查看軟體的已發布版本，建置它，並確保我可以重現它。為了確信能夠重現錯誤，我需要重現建置。此外，即使我確信錯誤在最近的開發過程中已順便修正，我仍然會爭辯說，至少有一個測試遺漏了。我想撰寫該測試，並驗證它現在通過，但會對已發布的建置失敗。

另一個情況是回歸。客戶與您聯繫，並表示現在有一個以前沒有的錯誤。此類錯誤可能潛伏很長一段時間，才會突然出現並對您揮舞觸鬚。也許它只會在每月的第一天是星期一的時候發生。無論如何，您現在擁有您認為兩個月前運作正常，但現在有錯誤的軟體。

在此，擁有可重現建置讓您可以使用 DiffDebugging。您的客戶相當確定您在兩個月前沒有這個問題，那是建置 20000，您現在在建置 28000。因此，您查看建置 20000，看看錯誤是否在那裡。它不在，因此您嘗試建置 24000，也不在，所以接下來是 26000。不久之後，您就會知道錯誤首次出現在版本 26543（現代版本控制系統 有 功能 來協助您執行此操作）。現在，您查看版本 26543 與其父版本之間的差異，這種方法通常可以讓您更輕鬆地找到錯誤。