James Shore writes that “Continuous Integration is an Attitude, Not a Tool“. I agree with first half of his post. Continuous integration _is_ a shared understanding among team members that all commits accompany a full integration and commits happen very often. I disagree, however, with the second half where he slams Cruise Control. Mr. Shore contends that CC is a crutch, and if you use it, “. . .it’s a clear sign that you have opportunities to improve”. I don’t disagree that my team has opportunities to improve, but the mere use of CC doesn’t cause this fact to be true. I agree with every one of his ideas:
- Team members ensure the build always works.
- When we get the latest code from the repository, it will always build successfully and pass all tests.
- We will check in our code every two to four hours.
- Cruise Control is a traffic cop that tells you when you broke the build
Mr. Shore’s main point is that you don’t need the traffic cop if you don’t break the build. I envy Mr. Shore if his team has never experienced a broken build. He makes a false assumption about users of CC. He assumes that users of CC, unlike his team, don’t run the build locally before committing. If his assumption were correct, then CC would always be the entity that reports problems.
My team’s routine is similar to Mr. Shore’s, but with the inclusion of CC. Before committing to the source code repository, we update to merge in the latest code. Next, we run the full build locally, and we make our commit ONLY if it builds. CC then is just an automated, independent build that should always pass. A broken build at the CC level is _always_ a surprise. Speed of the build is important, and it should constantly be improved. We focus on build speed since it is run locally as well as by CC.
CC may just be a traffic cop, but it saves time because it automates the steps of going to a different server to do an integration build, and it notifies early if one of us makes a mistake. Hopefully we don’t have to depend on Cruise Control (since our build should always work anyway) or the debugger (since the code should always work too). They may be used infrequently (both CC and the debugger), but they are valuable tools to have available.