Continuous Integration

One of my favorite all time blog posts about this topic is, "Continuous Integration is an Attitude, not a tool", in it James Shore describes the problems associated with using automated tools to run BVT's for CI:

This approach will lead to many more build problems and wasted time. First, you won't be running the full test suite before checking in, so the build will break more often. Second, you won't be "locking" the repository, so people will sometimes get code that doesn't work. Your test suite is likely to be slower, too, because you won't have to personally wait for the whole test suite to pass. This will allow you and your team to get away with sloppier, slower testing practices.

This is especially problematic when working with shared codebases that have a complex branching strategy and non-agile teams. Our team recently faced a huge challenge trying to stabilize our codebase and build as a result of relying on Cruise Control to exercise on Continuous Integration.

About 6 iterations into a project, our team was tired of dealing with these issues and dedicated a Friday afternoon kaizen meeting. We came up with a long list of action items to eliminate the muda related to our build but the irony of it all is that the build crashed and burned as we were leaving the meeting! This was yet another late Friday night we had to stay behind because of relying on Cruise Control!

In the spirit of kaizen, I would say that automated CI tools [are poka-yoke] that run poka-yoke artifacts [build scripts] to ensure an entire systems health. So isn't ok when CI tools catch errors in the build? Yes, but shouldn't we really be catching them before we commit? I am of the opinion that the limit of what a single build should contain is whatever is part of the bounded context. The CI tools should in fact build a system that contains many bounded contexts to ensure that it all works together, not to make sure that your commit hasn't broken some Fit tests.