As I noted in “Continuous Integration Best Practices—Part 1” there are 10 best practice principles associated with Continuous Integration and in this previous article, we looked at the first three. For part 2, we pick up where we left off and talk about principles four, five, and six.
For review, the full set of principles are outlined below:
1) Maintain a code repository
2) Automate the build
3) Make the build self-testing
4) Everyone commits to the baseline every day
5) Every commit (to baseline) should be built
6) Keep the build fast
7) Test in a clone of the production environment
8) Make it easy to get the latest deliverables
9) Everyone can see the results of the latest build
10) Automate deployment
4) Everyone commits to the baseline every day
There are two important points underlying this principle. The first point is that developers need to submit their code to the official, centralized repository. The purpose is to evaluate new submissions against the production code to avoid testing against outdated code or running into configuration issues. The second point regards the frequency of code check-ins. In order to emphasize the goal of quick iteration cycles, official CI doctrine advises developers to check their code in every day. This may not reflect the reality of most situations in the sense that we don’t want to check in just anything by days end—we want to check in working code, or better yet, a completed activity. The real point here is to have developers check in their work as soon as it’s complete. Don’t put off submitting the code and don’t try to bundle multiple activities into a single commit (new feature + bugfix + refactor).
5) Every commit (to baseline) should be built
In practice, the scale of development taking place will impact how literally this principle is followed. The goal here is simply to validate that each submission integrates cleanly with the established code base and does not introduce errors. If there are only a handful of submissions happening during the course of a day, such as in a small organization, then each submission should trigger a build. If, however, we are talking about a large organization with thousands of developers, it is prohibitively costly to run a build every time an individual developer submits code. In that type of situation some sort of intelligent batching or scheduling will need to be put into place and the overall principle of evaluating new submissions quickly should be the guiding idea.
6) Keep the build fast
This is a very simple principle to understand, but sometimes the implementation is tricky. Developers need rapid feedback in order to understand if their work was successful or not. Additionally, quick iteration cycles encourage experimentation because the impact on productivity is low. Achieving a quick build can be difficult due to many factors, including: size of the code base, network connectivity, reliance on specific shared resources, the programming languages involved, or the nature of the testing that needs to take place. In practice, some of the other principles may have to make concessions in order to keep the build fast. The reality is, a fast build is one of the more important aspects to implementing Continuous Integration and so wherever possible, optimizations for the sake of speed should be made.
David Hubbell
Software Engineer
SPK and Associates
Next Steps:
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
