Reputation: 2398
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
Upvotes: 1
Views: 256
Reputation: 1477
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.
Upvotes: 0
Reputation: 499062
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.
Upvotes: 0
Reputation: 8040
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.
Upvotes: 5