Bodhisattva in Training

October 23, 2011 Uncategorized

Continuous Integration Principles–Task Size Rules

Principles are those kinda things that you don’t have to believe in for them to exist.  For that matter they will still push you around without your consent.  I have never seen a set of Continuous Integration (CI) principles so I thought that I could share the ones that I have found through out my career.  The first one I elect to share is on task size…


Below is a loop diagram that shows some of the forces and effects task size can exert on CI.  If you have never seen a loop diagram before you can read this diagram by ideas relating to each other either in the same way or in the oppisite way.

As task size increases changeset size will increase as well.  People tend to commit changes when they have completed a task.

As changeset size increases so does the average time to fix a build.  When a build breaks and the changeset size was small it is generally easy to know what went wrong and fix it.  If the changeset size was large there are more things to suspect, investigate, and debug.  This takes longer.

As the average time to fix a broken build increases the build availability decreases.  This is assuming that you don’t allow committing changes to a broken build…the more often you have hard to fix builds the less available the build will be.

As the build is less available the changeset size will increase.  This is because developers will continue working while the build is not available, thus increasing the size of their changesets.

As changeset size increases the build stability will decrease. This is because the build breaks more often with large changesets than small changesets.

As build stability decreases the development environment tractability will decrease.  It is more difficult to work on a codeline that is unstable than a stable codeline.

As the environment tractability decreases the rate of change to the codeline will decrease.  Again it is more difficult to work on an unstable codebase.

As the rate of change decreases there will be less broken builds.  If you have a high rate of change you will have more broken builds.

As the number of broken builds increases the build availability will decrease.


I don’t mean to show this loop diagram as a standalone or complete system.  There are other forces that can come into play here to address the number of build breaks, how long it takes to fix a broken build, or even isolating build breaks.  These are important.  But they are not the core system.  This is the core system and the root input affecting the system’s output is the size of tasks.  If people are working with small tasks they will break the build far less often and when they do it will be easy to fix.  If people are working with large tasks they will break the build often and when they do it will be difficult to fix.  From what I have seen it works best when one or more small tasks can be completed in a day.  You will need to figure out what works on your project. 

You can also add to this diagram mitigating forces such as a precommit developer build to help control the number of broken builds.

P.S. If you are having a hard time getting task sizes down maybe you should draw a loop diagram of the forces at play keeping task sizes large on your project.

4 to “Continuous Integration Principles–Task Size Rules”


  1. […] Continuous Integration Principles–Task Size Rules has a diagram that seems about right — even if I haven’t really thought about it in great depth. […]

  1. A Smattering of Selenium #72 « Official Selenium Blog says...

    […] Continuous Integration Principles–Task Size Rules has a diagram that seems about right — even if I haven’t really thought about it in great depth. […]

  2. Kelly Summerlin says...

    The main fault I have with this diagram (and this thinking) is that there is only one build. CI is about integrating my code with other developer’s code, not about getting a build out there for QA. This means you need at least two builds. One build that is truly continuous on a build server meant to validate my code and your code as well as my tests and your tests work correctly when integrated. That build should never really “available” to anyone.

    A QA build on the other hand should integrate only things we know build correctly and have 100% passing tests (unit, integration tests). That build should theoretically always be available. But when that build is unavailable, it can be very hard to determine why it is unavailable, especially when the CI build is all green.

  3. Kelly Summerlin says...

    After reviewing your diagram again, I think I need to restate my previous comments. Your diagram seems to take the point that the CI build being broken causes stress and that stress is greater with larger change sets — which is absolutely true.

    Having worked with teams that are both very diligent about not breaking the build and teams that break the build about four or five times a day, I have become a proponent of separating the code that has yet to go through a green bar CI build. This means that code in the main branch has at least gotten past the CI gatekeeper. Code that breaks the CI doesn’t affect every other developer on the team, only the person(s) that checked in the breaking code. This usually means pulling from one branch and pushing to another CI branch (in git terms). The CI build is then responsible for pushing green bar change sets out to the main branch. Takes a little more discipline though.

Leave a comment