持续集成——持续的频率是多少
I'm setting up CruiseControl.net and I've never worked in an environment which used CI before.
I'm wondering whats the average/best practice of time between builds?
How often is continous?
Thanks,
Mike
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
连续通常意味着每次签入后都会发生构建。如果没有任何更改，则进行构建是没有意义的，并且如果您在签入后进行构建，那么如果构建失败，您可以确定问题是什么。每次签入主分支后，我们都会进行增量构建，并且每晚都会进行一次清理构建，以捕获增量有时会遗漏的依赖关系问题。
Continuous usually means that a build will happen after every checkin. There's no point in doing builds if nothing has changed, and if you build after a checkin then you can be certain of what the problem is if the build fails. We do an incremental build after every checkin to our main branch, and also a nightly clean build to catch dependency issues the incremental sometimes misses.
连续只是意味着每次签到。
由于每个项目都不同，因此没有普遍接受的时间长度。例如，为操作系统运行 CI 会比计算器应用程序花费更长的时间。
Continuous simply means on every check-in.
There is no universally accepted amount of time, since every project is different. Running CI for an OS would take longer than a calculator app, for example.
我会在每次登记时提高一个档次。如果您的应用程序具有项目间依赖关系（即我的 Web 应用程序依赖于构建 jar 或 dll 库的另一个项目）并且这种关系是紧密耦合的，那么只要有该依赖关系的新构建，我也希望进行构建。
基本上，您希望在应用程序有可能变得更糟之后尽快构建和测试。这样您就可以尽快发现新问题。
如果我做了一个更改，结果破坏了某些东西，那么 20 分钟后发现是否足够快？大概。但如果我能在 10 分钟后知道的话，我会很乐意接受。同上 5 分钟或 30 秒。从我破坏某件东西到我发现某件事情之间的时间越短，我修复它的成本就越低，因为我会更熟悉它，不太可能深入了解其他东西，也不太可能回家或吃午饭。我越快修复它，对我的队友的影响就越小。
I would up the ante on the every check-in a notch. If your application has inter-project dependencies (ie my web app depends on another project that builds a jar or dll library) and that relationship is tightly coupled, I would also want to build whenever there is a new build of that dependency.
Basically, you want to build and test as quickly as possible after there is a possibility of the application getting worse. That way you find out about new problems as quickly as possible.
If I make a change and it breaks something, is finding out 20 minutes later fast enough? Probably. But if I could find out 10 minutes later I'd happily take that. Ditto 5 minutes, or 30 seconds. The less time between when I break something and when I find out, the cheaper it is going to be for me to fix since I'll be more familiar with it, less likely to have got deep into something else, and less likely to have gone home or to lunch. And the quicker I fix it, the less impact it will have on my teammates.