持續集成服務器設置：從開發到生產

Question

我們正在重新配置我們的服務器環境，從開發到生產。 所有服務器都是作為VM運行的Windows 2008服務器。 我們將使用TeamCity進行持續集成和SubVersion作為我們的版本控制系統。

閱讀了一些建議后，這是我到目前為止計划的內容（不包括任何冗余，災難恢復等）：

• 生產： （1）Web服務器+（1）數據庫服務器
• 登台： （1）Web服務器+（1）數據庫服務器
• 構建： （1）SVN + TeamCity Web＆DB +（1）TeamCity代理
• 開發： （1）Web / DB服務器

因此，總共2個生產+ 2個分段+ 2-3個構建+ 1個Dev = 7-8個服務器

我的問題是：

1. SVN應該位於專用服務器上還是可以駐留在Dev服務器上？

   答：到目前為止的共識似乎是SV​​N 不應該在Dev服務器上。 它應該是獨立的，或者可以與TeamCity在同一服務器上配對。

2. TeamCity應該位於專用服務器上還是可以駐留在SVN服務器上？

   答：到目前為止，人們普遍認為TeamCity 可以與SVN位於同一台服務器上，特別是如果TeamCity代理和SQL DB位於不同的服務器上時。

3. 還有其他建議，最佳做法嗎？

   答案： TeamCity應該分為3個服務器實例：一個用於TeamCity Web，一個用於TeamCity代理，一個用於TeamCity SQL DB。

我正在嘗試建立可靠的最佳實踐設置，同時最大程度地減少服務器蔓延。

Answer 1

要回答您的問題：

• 我會將SVN放在與開發服務器不同的服務器上。 通常，各種垃圾會安裝在開發服務器上。
• TeamCity可以與SVN服務器位於同一服務器上。 （將其稱為構建服務器）
• 您的生產系統沒有內置任何彈性。
  我建議至少再有兩個服務器，另一個Web服務器和一個熱備用DB服務器，該服務器是從活動DB服務器鏡像的。
  這些服務器不應與其余服務器位於同一數據中心，而應使用替代網關連接到Internet。

Answer 2

我剛剛使用SQL Server DB設置了TeamCity，並且在同一Windows VM上都在Tomcat上運行的webapp實例被設置。

• TeamCity Web服務器在Tomcat本身上運行，並使用大量內存（就像任何Tomcat應用程序一樣）。
• 由於TeamCity Build代理會進行編譯，因此它們會占用大量內存。
• SQL Server是一種內存消耗。

JetBrains提到Build代理最好不要與Web服務器在同一服務器上運行。 我建議也將數據庫分開（放在一個物理盒子上，而不僅僅是一個VM上），以便CI設置本身使用3個系統（TeamCity Web服務器，TeamCity數據庫，TeamCity構建代理）。 如果您的構建花費了幾分鍾以上的時間，我將添加另一個構建代理服務器，以使開發人員不會在提交時排隊，特別是如果您正在使用IDEA或Eclipse的TeamCity的遠程運行/個人構建功能。

將SVN服務器與TeamCity Web服務器安裝在同一系統上不會有問題。

請記住，編譯是通常受CPU限制或磁盤訪問限制的活動。 構建代理將從分離到單獨的CPU和/或磁盤中受益。 但是，由於多個VM的開銷，在共享磁盤和CPU的單獨VM上可能比幫助有用更多的浪費。