fbpx
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

Guide to work management: Tools for teamwork

Guide to work management: Tools for teamwork

Ensuring collaboration between cross-functional teams can be challenging, especially when these teams are global. Fortunately, there are many tools on the market that mitigate these struggles. Atlassian’s suite of tools helps teams across the globe collaborate like...

Related Resources

The Role of Jira and Confluence After Mergers or Acquisitions

The Role of Jira and Confluence After Mergers or Acquisitions

Mergers and acquisitions (M&A) are complex processes that bring new opportunities, expanded teams, and a broader range of tools and technologies.  For many companies, the aftermath of an acquisition includes managing disparate systems. This is especially true when...