spk-logo-white-text-short
0%
1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

Continuous Integration Best Practices—Part 3

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:

Latest White Papers

The Hybrid-Remote Playbook

The Hybrid-Remote Playbook

Post-pandemic, many companies have shifted to a hybrid or fully remote work environment. Despite many companies having fully remote workers, many still rely on synchronous communication. Loom offers a way for employees to work on their own time, without as many...

Related Resources

How Model-Based Definition (MBD) Cuts ECOs by 41% and Scrap by 47%

How Model-Based Definition (MBD) Cuts ECOs by 41% and Scrap by 47%

Organizations are increasingly turning to Model-Based Definition (MBD) to revolutionize their engineering and manufacturing processes. By embedding rich, digital annotations directly into 3D models, MBD provides a single source of truth for product definitions. This...

Seamlessly Transition from AWS CodeCommit to GitLab

Seamlessly Transition from AWS CodeCommit to GitLab

In July of 2024, AWS announced that AWS CodeCommit would no longer be sold to new customers.  And thus begins the journey of winding down a product for AWS.  As AWS CodeCommit approaches its end-of-life, many organizations face a tough decision. Choosing where to...