集中式持续集成/构建设置与集中式持续集成项目特定的构建设置
与特定于项目的设置相比，集中式持续集成/构建设置（在我们的例子中它将是巡航控制）有哪些优点/缺点？
到目前为止，我们已经有了一个特定于项目的 Cruisecontrol 设置，但现在许多其他团队也希望迁移到 CI，并且需要一个中央 CruiseServer。我想知道是否有人有任何经验（好/坏）可以分享，可以帮助我解决这个问题。
以下是一些初步想法：
优点：中央系统易于管理，避免整个组织在为各种项目设置和维护巡航实例时重复工作。
缺点：中央系统可能必须在访问等方面进行更受控制的设置，因此可能需要由专门的人员/组拥有，而项目巡航实例可以在项目组的控制下，进行更改/增强速度更快并且针对特定项目。
如果有任何意见，我将不胜感激。
What are the pros/cons of having a centralized continuous integration/build setup (in our case it will be cruise control) as opposed to project-specific setup?
So far, we had a project specific setup of cruisecontrol, but now many other groups want to move to CI as well, and are asking for a central cruiseserver. I'd like to know if anyone has any experience (good/bad) to share that can help me on this.
Here are some initial thoughts:
Pros: A central system would be easy to administer avoiding duplication of efforts all across the organization in setting up and maintaining cruise instances for various projects.
Cons: The central system may have to be a more controlled setup w.r.t access etc., and hence may need to be owned by a dedicated person/group, while the project cruise instances can be under the control of the project group, making changes/enhancements faster and project-specific.
I'd appreciate any inputs on this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们的集中式系统面临的一个问题是队列长度。系统上的项目越多，您需要等待的时间就越长。或者您必须将 CI 拆分为分布式任务。
One issue we have with our centralized systems is queue length. The more projects you have on the system the more time you have to wait. Or the more you have to split your CI into distributed tasks.