Continuous Integration – Executive Summary
Continuous Integration (CI) is a strange concept from the perspective of an outsider. Some of our topics in software development make sense from the outside. Unit tests imply we are adding some value to our development process. Requirement gathering makes sense to almost anyone.
But the concept of Continuous Integration seems a little bit like priming the antimatter engine. Does it make sense from the outside? Probably not. But just because it doesn’t make sense from the outside doesn’t mean it doesn’t make sense.
Continuous means something we are going to keep doing something all the time. Integration means connecting multiple pieces. Together, the words say that we want to integrate things all the time. Every check-in, every pull request, every change we want to validate in a build.
Why is this important? CI is one of those baseline things you want in every project. With CI, we discover many of those integration issues that tend to occur toward the end of a project. The stabilization phase that occurs near the end of a project can easily consume half of that total time. By continuing to perform those integrations, you should be able to cut that time down drastically. This means you are paying a little penalty each week instead of a big penalty at the end.
What do we do as part of CI?
- Builds
- Automated Tests
- Deploy to a QA environment
CI by itself won’t save your project; it isn’t a magic bullet or a magic wand for your integration problems. But trying to run fast without a good CI setup can be a pretty rough road.
If you have more questions about continuous integration, or any stage of the software development process, hit me up on Twitter or respond in the comments below.
