持续集成服务器设置：从开发到生产
我们正在重新配置我们的服务器环境，从开发到生产。 所有服务器都将是作为虚拟机运行的 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 台开发 = 7-8 台服务器
我的问题是：
- SVN 应该位于专用服务器上吗？或者它可以存在于开发服务器上吗？ <块引用>
答案：到目前为止，共识似乎是 SVN 不应该位于开发服务器上。 它应该是独立的，或者可以与 TeamCity 在同一服务器上配对。
TeamCity 应该位于专用服务器上，还是可以驻留在 SVN 服务器上？
<块引用>答案：到目前为止，共识是 TeamCity可能与 SVN 位于同一服务器上，特别是当 TeamCity 代理和 SQL DB 位于不同的服务器上时。
还有其他建议、最佳实践吗？
<块引用>答案：TeamCity 应分为 3 个服务器实例：一个用于 TeamCity Web，一个用于 TeamCity Agent，一个用于 TeamCity SQL DB。
我正在尝试建立可靠的最佳实践设置，同时最大限度地减少服务器的蔓延。
We are in the process of re-configuring our server environment, from Development to Production. All servers will be Windows 2008 servers running as VM's. We will be using TeamCity for Continuous Integration and SubVersion as our Version Control System.
After reading some of the recommendations, here is what I am planning on going with so far (not including any redundancy, disaster recovery, etc...):
- Production: (1) Web Server + (1) DB Server
- Staging: (1) Web Server + (1) DB Server
- Build: (1) SVN + TeamCity Web&DB + (1) TeamCity Agent
- Development: (1) Web/DB Server
So a total of 2 Production + 2 Staging + 2-3 Build + 1 Dev = 7-8 Servers
My questions were:
- Should SVN be on a dedicated Server, or can it live on the Dev server?
Answer: Concensus so far seems to be that SVN should not be on the Dev server. It should either be standalone, or could be paired up on the same server as TeamCity.
Should TeamCity be on a dedicated Server, or can it live on the SVN server?
Answer: Concensus so far is that TeamCity could be on the same server as SVN, particularly if the TeamCity Agents and SQL DB are on separate servers.
Any other recommendations, best practices?
Answer: TeamCity should be split up across 3 server instances: One for TeamCity Web, one for TeamCity Agents, and one for the TeamCity SQL DB.
I'm trying to have a solid best-practice setup while minimize server sprawl.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
回答你的问题：
通常，开发服务器上会安装各种垃圾。
我建议至少再有两台服务器，另一台 Web 服务器和一台从实时数据库服务器镜像的热备用数据库服务器。
这些服务器不应与其他服务器位于同一数据中心，并且应使用替代的互联网网关。
To answer your questions:
Often all sorts of rubbish is installed on dev servers.
I would suggest having a minimum of two more servers, another web server and a hot standby DB server which is mirrored from your live DB server.
These should not be at the same data center as the rest of your servers, and should use alternative gateways to the internet.
我刚刚使用 SQL Server DB 设置了 TeamCity，并且在同一 Windows VM 上运行在 Tomcat 上的 Web 应用程序实例。
Tomcat本身，用处很大
内存（就像任何 Tomcat 应用程序一样）。
编译，使用大量内存。
JetBrains 提到，构建代理不应最佳地与 Web 服务器运行在同一服务器上。 我建议数据库也分开（在物理机上，而不仅仅是虚拟机上），以便 CI 设置本身使用 3 个系统（TeamCity Web 服务器、TeamCity 数据库、TeamCity 构建代理）。 如果您的构建需要几分钟以上，我会添加另一个构建代理服务器，这样开发人员就不会在提交时排队，特别是当您使用 IDEA 或 Eclipse 中的 TeamCity 远程运行/个人构建功能时。
将 SVN 服务器与 TeamCity Web 服务器放在同一系统上不会有任何问题。
请记住，编译是一项通常受 CPU 限制或磁盘访问限制的活动。 构建代理将受益于分离到单独的 CPU 和/或磁盘上。 然而，由于多个虚拟机的开销，位于共享磁盘和 CPU 的单独虚拟机上可能浪费多于帮助。
I've just set up TeamCity using SQL Server DB and an instance of our webapp running on Tomcat all on the same Windows VM.
Tomcat itself, and uses a good deal
of memory (like any Tomcat app).
compile, use a ton of memory.
JetBrains mentions that Build agents should not be running on the same server as the web server optimally. I'd suggest that the database be separated as well (onto a physical box, not just a VM), so that the CI setup itself uses 3 systems (TeamCity web server, TeamCity database, TeamCity build agent). If your builds take more than a few minutes, I'd add another build agent server so that developers aren't queued up on commits, especially if you are using TeamCity's remote run/personal build feature from IDEA or Eclipse.
I wouldn't have a problem putting the SVN server on the same system as the TeamCity web server.
Keep in mind that compiling is an activity that is typically CPU-bound or disk access-bound. Build Agents will benefit from being separated onto separate CPUs and/or disks. However, being on separate VMs that are sharing disks and CPUs may be more wasteful than helpful due to the overhead of multiple VMs.