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.