Subversion，TeamCity和開發服務器的服務器體系結構

Question

我爲一家較新的.Net CMS Web開發公司工作，現在我們正在制定一個版本控制策略。我們目前傾向於顛覆Subversion的版本控制系統，以保持我們的開發服務器更新（並將我們的構建控制到質量保證和生產）。

我正在嘗試找出建議的建議類型的架構。我們應該爲每個服務器分開嗎？怎麼樣TeamCity服務器和建設代理（S）？在我看來，最好的辦法是設置一臺服務器來運行Subversion，一臺運行TeamCity Server，另一臺運行TeamCity Build Agent。但是，我們希望避免爲此運行三臺獨立的服務器。

任何人都可以告訴我他們之前使用過什麼，哪些效果很好？你有什麼建議？爲什麼？

更新：我們需要支持大約10個開發人員。我們現在有點不高興，但預計明年會僱用幾個/幾個。

更新：還有一個問題。根據我們使用的開發人員的數量，通過閱讀文檔，我們很可能不需要超過專業服務許可證的三個Build Agent。看起來，如果我們有更多的開發人員，這需要增加，但不一定是活動項目的數量。這是否準確？

Answer 1

我們必須承載的TeamCity，並作爲構建SQL Server代理存儲

一個服務器

• 一臺服務器。 TeamCity數據庫不是那裏唯一的數據庫。
• 兩個額外的構建代理服務器。

我們爲多個團隊構建了多個項目。

最初在一個團隊中只有少數開發人員。一臺服務器充當TeamCity服務器，TeamCity代理和數據庫服務器，我們很好。

除非您想一次構建多個項目，否則您不需要多個代理，或者您的構建時間很長。我們發現開發人員的數量並不是一個直接的因素。同時運行的版本數量更重要。這可能與開發人員的數量有關，但這不在我們的情況。我們的構建時間很短（3分鐘），我們一次只限制一個項目的構建。

Answer 2

這取決於你的團隊的規模。我的公司有12個開發人員。

• 我們有一個TeamCity web服務器，它也是一個構建代理。
• TeamCity數據庫位於我們已擁有的另一個SQL Server上。
• Subversion在我們已有的另一臺服務器上。
• 我們使用了兩臺開發人員機器作爲第二個和第三個構建代理。

但是對於一個小團隊來說，你可能會把它們放在一個功能相當強大的服務器上。你必須看到什麼適合你。