As I noted in “Continuous Integration Best Practices—Part 1” and “Continuous Integration Best Practices—Part 2” there are 10 best practice principles associated with Continuous Integration and in this previous articles, we covered the first six. In this article, we pick up where we left off and talk about principles seven and eight.
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
7) Test in a clone of the production environment
I, for one, would be very hesitant to board a new airplane that was only evaluated in a wind tunnel and had previously never attempted actual flight. While performance characteristics and issues can be determined in the testing environment of a wind tunnel, it does not subject the craft to the same conditions as the “production” environment (i.e. the sky). In the same way, complex software products cannot truly be considered “tested” if the testing environment does not replicate or at least mimic the characteristics of the production environment.
The ideal goal is to have a pre-production or “staging” area that represents a clone of the production environment and have each build deploy to this staging environment for automated testing. However, this principle is another example in which the ideal is often unattainable in practice and therefore the objective is to come as close to meeting it as is allowed by your given set of constraints. Rather than a one-to-one clone of production, we must make due with a scaled version.
8) Make it easy to get the latest deliverables
When a build and test cycle completes, there should be artifacts produced by the process. These could be compiled binaries, class files, executables, documents, testing results, or reports. Anything that was produced. This principle states that accessing this set of artifacts should be relatively easy for authorized parties.
Several groups of people related to a project can benefit from using this principle. In the event of successful builds, this is useful for allowing stakeholders access to the product in order to evaluate it on their own terms and provide feedback as things progress. In the event of failed builds, easy access to the inputs and outputs of a build can reduce the time necessary for QA to identify the source of the failure. The idea, again, is to reduce the time it takes to get feedback. Easy access for stakeholders means faster feedback from that group which equates to how closely the project is tracking with the requirements. Easy access for QA means they don’t have to waste time rerunning a build in order to obtain artifacts for diagnostic purposes. If done well, easy access to deliverables can make it possible to further optimize the build process itself. By this I mean that if you are 100% certain that the current set of changes has no impact on a specific set of artifacts, you can reuse those unaffected artifacts from a previous successful build instead of wasting time rebuilding them, thus shortening the feedback loop for developers.
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.
