企业 CI (SOA/.Net)
我应该如何解决 SOA 平台的持续集成问题？
让我解释一下设置。我们有 30 个 Web 服务解决方案和 5 个客户端解决方案，Web 服务彼此相当依赖（引用合约 dll），并且还共享一些通用实用程序 dll。
到目前为止，我们对 CruiseControl.net（37 个 CC 项目、5 个客户端、30 个 WS、1 个实用程序项目、1 个集成测试项目）感到满意，所有构建和测试都是相互独立的。在每次部署之前，我们都会按照明确定义的顺序触发所有项目的构建，这为我们提供了准备好的部署工件以部署到大约 7 个不同的服务器。
到目前为止，我们还没有任何服务版本控制，每次部署都会部署完整的 shebang。
我们最近投入生产，现在需要对代码进行分支，以便任何进一步的开发都不会扰乱我们对现在生产中的内容进行热修复的能力。
此外，我们希望分散我们的工作，产生单独的开发工作，创建新客户端或将主要功能添加到现有客户端/服务中，我认为我们需要以下内容
这样我们就可以轻松地修复产品，我们将继续根据每月的用户反馈改进产品，并且我们可以在 SOA 堆栈上启动新的主要工作，而不会干扰前两个（直到我们合并代码）那是:) ）
问题是：我们应该使用什么工具来进行 CI？ 我看到的选项：
- 在我们的 ccnet 实例中重复项目
- 重复 ccnet：xcopy CCnet 到构建机器上的 X 位置，在不同端口上设置新服务，调整 svn 源，构建位置和部署工件位置
- 使用更适合这些的不同 CI 服务器问题
1：我不喜欢它（笨拙，什么时候是绿色的，所有团队都使用同一个池）
2：我可以看到我们这样做，但感觉有点笨拙
3：我们应该使用哪个服务器？到目前为止，我听说过 Hudson 和 Cruise 这两个名字，这些可以用吗？
4：我的想法完全错了吗？你们其他人如何在 SOA 堆栈上进行 CI 来支持许多团队的开发工作？
How should I tackle Continuous integration for a SOA platform?
Let me explain the setup. We have 30 web service solutions and 5 client solutions, the web services are quite dependent on each other (references contract dlls) and also share some common utility dlls.
Until now we have been happy with CruiseControl.net (37 CC projects, 5 clients, 30 WS, 1 utility project, 1 integration test project) all building and testing independent of each other. Before each deploy we trigger the builds for all projects in a well-defined order which gives us ready deploy-artifacts to deploy to some 7 different servers.
Until now we haven't had any versioning of services, and each deploy would deploy the complete shebang.
We recently went into production and now we need to branch out the code, so that any further development does not mess up our ability to hotfix what is in production now.
Also we want to split up our efforts, spawning separate development efforts creating new clients or adding major functionality into existing clients/services, what I'm thinking is that we need the following
that way we can always hotfix prod with very little effort, we will continue to improve prod based on user feedback on a monthly basis, and we can launch new major efforts on our SOA stack without interfering with the first two (until we merge the code that is :) )
The question is: what tools should we use for CI?
options as I see them:
- duplicate projects within our ccnet instance
- duplicate ccnet: xcopy CCnet to X locations on build machine, setup new services on different ports, tweak svn source, build location and deploy artifact location
- use a different CI server more suited to these problems
1: I don't like it (unwieldy, when is it green, all teams use same pool)
2: I could see us doing this, but it feels a bit clunky
3: Which server should we use? So far I've heard the names Hudson and Cruise, would these be applicable?
4: Have I thought completely wrong? How do you other guys do CI on a SOA stack that is meant to support many teams' development efforts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会将 Teamcity 加入其中。它使用构建代理网格，可以为您提供更多的马力以及执行同步构建的能力。
由于项目数量庞大，可能很难在任何特定构建服务器的同一实例中将构建复制三次。在同一页面上需要跟踪的项目将超过 100 个。
选项 2 绝对可行，尽管我可能会考虑利用虚拟机，创建一个构建服务器映像，然后托管该映像的三个实例，这将产生三个不错的 url，而无需使用不同的端口以及需要维护的三个相同的设置。
另外一个考虑因素；也许您可以通过对相关组件进行分组并使用 nant\msbuild\ruby\powershell 脚本将超过 37 个项目折叠成更少的 ccnet 构建。如果您可以将构建减少到 15 个，那么在同一服务器实例中运行所有三个变体将变得更加可行。
I would throw Teamcity into the mix. It uses a grid of build agents which may be able to give you a little more horsepower as well as ability to perform simultaneous builds.
With your sheer number of projects it might be tough to replicate your build three times within the same instance of any particular build server. That would be over 100 projects to keep track of on the same page.
Option 2 is definitely viable although I might consider leveraging virtual machines, creating one build server image, and then hosting three instances of that which would result in three nice urls without using different ports as well as three identical setups to maintain.
One other consideration; perhaps you could collapse your 37+ projects into fewer ccnet builds by grouping related components and using nant\msbuild\ruby\powershell scripting. If you can get down to 15 builds then running all three variations in the same server instance becomes more viable.