Just watched a video about continous delivery and there it was suggested to trigger a build and execute unit test on each commit. For our team of 10 developers and a build time of at least 10 minues I wonder how this will work as in 1 hour, all developers might deliver something ==> we might end up having multiple ongoing builds simultaneously.

Would that be ok ? Is that a good practice ?

Currently the build is triggered manually on demand.

  • 3
    10 minutes is a long build time. In your case, I would go on a schedule, maybe 4x a day, every hour or similar. I think the point is build and test early and often as opposed to less frequent builds.
    – Jon Raynor
    Oct 25, 2016 at 16:53
  • @JonRaynor 10 minutes is a long build time - in some cases yes, but in others 6h builds are fast :) Mar 17, 2017 at 4:06

2 Answers 2


Most, if not all CI platforms limit you to a single build per project/branch.

If your developers are working on separate branches, then you may indeed have concurrent isolated builds. This may cause a backup at the CI server, but it can be resolved by adding more slave machines to run the builds.

If they're working on the same branch, then the builds will happen one after another, one per commit. If you commit too frequently for the CI server to keep up, this may be a problem, although you could replace the commit-based triggering with time-based triggering.

BUT, if you're following good development practices, and the developers merge changes and run unit tests prior to commit, then the time taken by the developers should (over the long run) match that of the CI build machines.

If your developers are making changes in very different parts of the codebase, then a followup step is to break the project into multiple sub-projects (libraries) and edit/test/build them independently.


Well, the suggestion to execute your CI verifications for every commit is simply an attempt to make the integration more deterministic: the first failing verification would immediately point to the faulty changeset, so only the repair would remain to be done for the branch to recover from the quality regressions.

If several changesets are committed between 2 consecutive verifications a failure would only indicate the group of changesets containing the culprit. An additional effort for exactly identifying the culprit would be required before the repair chan be made. Which typically doesn't take a fixed/deterministic amount of time. So overall the blockages caused by the regressions would be longer.

Even verifications after every commit aren't a silver bullet - they're effective only as long as multiple regression-causing changesets aren't committed too close to each-other: if one or more subsequent such changesets are committed before the verification for the 1st one completes (with a failed result) and that 1st changeset is backed out then backing out the 1st changeset won't bring the branch in regression-free condition - the other regression(s) will still exist, but potentially without a clear indication of the culprit, which again would translate into longer blockages.

The above are just a few reasons for which CI systems based on post-commit verifications are subject to congestion in high velocity projects. For more details see my Congestion in Traditional CI Systems post. Disclaimer: I am afiliated to the company mentioned in this post.

You might want to eventually consider a pre-commit based CI system, see Is there a CI tool that guarantees no regressions in the branch quality level?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.