待處理的 Head

我是 持續整合 的忠實愛好者，這是一個相對簡單的實務，可以為大多數開發團隊帶來極大的改變。然而，就像大多數實務一樣，它有其缺點^H^H^H^H^H 改進的機會。保羅·杜瓦爾 是這方面的 即將成為標準書籍 的作者，他 指出 近期其中一項。如果提交的版本組建中斷，整個團隊都會受到影響，並可能在修復之前減緩進度。

當我們最初在 Thoughtworks 開始進行持續整合時，這是我們執行方式中讓我擔心的事情之一。這讓我擔心，因為 Thoughtworks 2000 風格和我們在 C3 使用的風格之間存在著重要的差異。

Thoughtworks 2000 風格幾乎是當今使用的 CI 的標準風格。一旦你對自己的工作感到滿意，就可以將其提交到儲存庫，然後在組建機器上組建它（手動或使用類似 CruiseControl 的 CI 伺服器）。如果你的提交有問題，問題就出現了，任何更新的人都將獲得失敗的程式碼，直到你修復它為止。

在 C3 的執行方式中，我們沒有直接提交到儲存庫的頭部。C3 是 Smalltalk 專案，並使用 Envy，一個以 Smalltalk 為導向的儲存庫系統。Envy 有一些與主流儲存庫不同的概念。由於我已經很久沒有使用它了，所以我對它的運作方式的記憶已經變得模糊不清，但基本的想法是，當你正在開發你的功能時，你會提交到版本。版本就像一個私有分支，所有人都可以看到，但沒有得到認可。只有當你在組建機器上成功組建時，你才會將你的版本升級為版本，這等同於主線。這樣你永遠不會讓中斷的程式碼進入專案的主線。

Envy 讓以這種方式工作變得容易，我們現在主要使用的版本控制系統讓它變得更加棘手。理想情況下，你希望建立一個工作副本，從真實的頭部更新（以保持同步），但提交到不同的待處理頭部分支。只有成功的整合組建才能實際提交到真正的專案頭部。持續整合伺服器將從待處理頭部簽出，如果成功，則提交到真實頭部。

自己設定這樣的東西有多困難？我不確定，我沒有與完成此項工作的團隊聊過。然而，許多團隊導向的工具都提供了這種功能。例如，JetBrains 的 TeamCity 以「延遲提交」的名義執行此操作。保羅還提到了 Borland 的 Gauntlet。

另一個問題是它有多重要。儘管我擔心我們無法從中斷的建置中獲得足夠的痛苦，而想要在 2000 年安裝掛起的頭端。如果您獲得許多中斷的整合建置，還有其他方法可以修復它。通常，主要問題是人們在提交之前沒有進行私人建置。與往常一樣，在引入更複雜的技術之前，人員問題通常是更重要的問題。