「延遲提交」如何與源代碼控制存儲庫和CI服務器一起使用？

Question

我想知道「延遲提交」功能如何在未與源代碼控制存儲庫集成的CI服務器上工作。從概念上講，過程就像如下：

1. 入住代碼更改
2. CI服務器構建的變化
3. 如果構建通過，代碼提交如果構建沒有源代碼控制庫
4. ，該代碼未提交到源代碼管理存儲庫

大多數CI服務器通過輪詢源代碼管理存儲庫以查找更改，然後下拉代碼來工作。因此，在延遲提交場景中，開發人員是否將他們的代碼檢查到CI服務器而不是實際的源代碼控制存儲庫，然後CI服務器是否將代碼傳遞到存儲庫？或者，如果構建失敗，CI服務器是否會回滾更改？

我特別想到兩個持續集成系統。 Team Foundation Server將在下一版本中提供此功能，但它很有意義，因爲TFS中的Team Build（CI系統）已與源代碼管理存儲庫集成在一起。但是，就Team City而言，TC能夠連接到任何源代碼管理系統，並且不一定與源代碼管理系統庫集成在一起，甚至不在與源代碼管理系統庫相同的服務器上。這是如何工作的？

編輯：在這個問題上打開賞金，希望我可以得到更多可能的答案。

Answer 1

通常，您必須使用命令行工具或IDE插件，以便您將代碼提交給CI服務器。該工具將所有相關的項目/存儲庫/用戶元數據與更改捆綁在一起，開始構建並在一切順利時提交。

在TeamCity的情況下，它看起來像服務器實際上提交批准消息返回到您的計算機（from what I can tell from the diagram），那麼它就會從那裏—致力於想必，這樣你就不需要有每個用戶的SCM憑據—這如果您在TC服務器上使用SSH私鑰等—可能會很複雜。

但是CI服務器可以集成幾乎所有的SCM系統，無論服務器位於何處—只需要給它正確的憑據即可獲得（通常只讀）訪問權限。

Answer 2

它做這樣的事情：

TeamCity Pre-test commit http://kawalerowicz.net/ch4_11.gif

所以它是客戶機，它的承諾。不是服務器。 SCM在這種情況下並不重要。