到目前爲止，我只使用TeamCity作爲連續構建服務器。沒有真正的整合。現在，我需要將一個共享項目的輸出複製到兩個其他依賴項目中，並依次啓動它們的自動構建。也就是說，ProjectA和ProjectB都依賴於ProjectC。當任何提交發生在其各自的存儲庫中時，所有三個目前都由TC構建。我們的願望是將ProjectC的輸出複製並提交給ProjectA和ProjectB。這樣的提交反過來會啓動兩個依賴項目的構建過程。這似乎是在談論持續集成時常見的情況。不是嗎？爲了澄清，我們使用TeamCity v.4.5.5（build 9103），SVN和nAnt作爲我們的build runner。TeamCity能否將一個構建的輸出提交給另一個svn庫，從而啓動另一個構建？
編輯：我錯誤地說了一些關於提交到另一個存儲庫。實際上，他們三個都駐留在同一個物理存儲庫中，僅在層次結構的不同層次上。
我不知道TeamCity是否支持這個功能，但這應該很容易通過腳本來完成 - 作爲在ProjectC中構建的最後一步，添加一個腳本來檢出ProjectC目錄（不是整個存儲庫，只是您的目錄保留ProjectC和ProjectB的二進制文件），複製所有需要的文件並提交一些自動生成的消息 - 看起來很簡單。
但是 - 這是危險的。 ProjectA和ProjectB的構建可能會因ProjectC的API更改而中斷，或者某些未經測試的代碼部分已損壞。這可能會破壞團隊A和B的工作。我會尋求解決方案，新版本的庫每天/每週/任何其他時間段進行一次提交。另外，創建一個自動更改日誌可能是一個好主意 - 例如，如果您信任svn日誌消息的質量，則可以從提交版本中包含的所有「新」提交創建更新日誌（或追加當前日期日誌消息，如果您決定在每次提交後選擇推送新庫）。通過這種方式，負責ProjectA和ProjectB的團隊將能夠輕鬆修復他們的構建，如果新庫破壞它們 - 他們將確切知道發生了什麼變化，無需手動檢查/詢問團隊C.
偉大的提示。看起來TeamCity並不直接這樣做，所以編寫腳本就是我現在所處的位置。你也讓我停下來，想一想每次在ProjectC上提交後是否希望發生這種情況。我想可能在夜間搭建就足夠了。自動更改日誌的想法也很有趣。從來沒有想過這樣做。不過，我不確定是否足夠信任日誌消息。 – Kilhoffer 2009-12-09 21:27:00
通常，您不會將構建輸出提交到您的存儲庫。你確定這就是你想要的嗎？
您可以使TeamCity將輸出（工件）從一個構建項目複製到另一個構建項目的目錄中，但爲了提交它，您需要添加一些腳本，如批處理文件或類似文件。
在這種情況下，ProjectC成爲ProjectA和ProjectB的第三方。因此，它的輸出應該存在於兩個項目的'lib'文件夾中，以及其他第三方組件。所以，是的，承諾的輸出絕對是我想要的。使用像ProjectA，ProjectB和ProjectC這樣的名稱作爲示例，但實質上，這些項目中的每一個都由業務的不同部分所有，並且不會彼此編輯。因此，在這種情況下，ProjectC以彙編格式提供給消費者是可取的。 – Kilhoffer 2009-12-09 20:42:05
在較新版本的TeamCity您可以定義工件依賴關係，這將允許您按照您的示例創建「庫」，並將該構建的工件拖放到其他項目中。如果您使用類似Node.js/npm的東西來構建項目，您還需要捕獲輸出文件夾（例如'dist'），以便在還原工件時可以解壓縮單個文件夾而不是依賴。
如果任何人有興趣，我可以擴展這個例子，只是想讓人們通過谷歌找到它，現在更容易做到。
你最好讓其他項目的構建腳本從原始構建中拉取二進制文件。這給了你更多的靈活性，並且意味着你不太可能不經意間破壞了這些項目。 – 2011-11-08 15:52:17