1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

Optimal Continuous Integration Best Practices (Part 3)

Published by Carlos Almeida
on November 4, 2021
November, 2021 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. In the 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

Number Seven (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 never attempted actual flight. Certainly, engineers can determine performance characteristics in the testing environment of a wind tunnel.  But, it does not subject the craft to the same conditions as the “production” environment (e.g., the sky). In the same way, complex software products are not truly “tested” if the testing environment does not replicate  the characteristics of the production environment.

The Role of the “Staging” Environment

The ideal goal is to have a pre-production or “staging” area that represents a clone of the production environment.  Then, deploy each build to this staging environment for automated testing. Having said that, this principle is another example in which the ideal is often unattainable in practice.  Therefore, the objective should be to come as close to meeting this principle as is allowed by your constraints. Rather than a one-to-one clone of production, we must usually make do with a scaled version.

Number Eight (8):  Make It Easy To Get The Latest Deliverables

When a build and test cycle is completed, artifacts are produced. These artifacts could be compiled binaries, class files, executables, documents, testing results, or reports. Principle 8 states that it should be relatively easy for authorized parties to access these deliverables.

Check-In the Deliverables

It is better to use checked-in deliverable artifacts rather than simply doing a pull of the code. Why? The artifacts generated during the testing phase are immutable. Therefore, when the artifact is pulled into a production environment, it is guaranteed that it was tested and that there haven’t been any changes since then, no matter how small. If anybody has the question, “Are we sure this is the same thing we tested?” you can generate an audit trail that proves it. There are several groups of people in a project that can benefit from using this principle. If the build is successful, non-developer stakeholders can access the product for evaluation and to provide feedback. If the build failed, having easy access to the build deliverables reduces the time required for QA to identify the root causes. Again, reduce the time it takes to get feedback.

Make it Easy = Faster Feedback

Easy access for stakeholders means faster feedback. Faster feedback accelerates the software lifecycle by allowing rapid evaluation of how closely the project is tracking against the requirements. Easy access for QA means they don’t have to waste time re-running 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. Basically, the stakeholders don’t need to waste time rebuilding the deliverables. Therefore, the feedback loop is further shortened for the developers. Joshua Kling, Software Engineer (SPK)

Next Steps:

  1. Take stock of your current SDA process. Contact SPK to help identify potential improvements and a methodology to get there. Then enjoy faster development times, greater visibility, and more automation!
  2. Contact SPK and Associates to learn more about our continuous integration and continuous delivery services, and flexible solutions for your company’s needs.
  3. Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
  4. Subscribe to our blog to read further about smart engineering technology solutions and development operations topics.

Latest White Papers

6 Secrets To A Successful Atlassian Migration At Scale

6 Secrets To A Successful Atlassian Migration At Scale

With large scale migrations, large user bases, multiple Atlassian tools, plenty of apps, and lots of data, moving to Atlassian Cloud may feel like a steep mountain to climb. But, it doesn't have to be. In fact, we've already helped many customers make the move. Plus,...

Related Resources

Jira Cloud vs Azure DevOps Cost: Are You Paying Too Much?

Jira Cloud vs Azure DevOps Cost: Are You Paying Too Much?

Choosing the right issue and feature tracking tools to manage your software development lifecycle is important. It can be the difference between speed to market, budget savings and even boosting DevOps team morale. Whilst there are plenty of tools in the market, in...

Data Engineering Supports Digital Transformation

Data Engineering Supports Digital Transformation

Data engineering supports digital transformation. Fact. But, how do companies move away from more paper processes and towards digital transformation? It’s not easy. And, the larger the organization, the more difficult it is. Companies can take solace in knowing there...

What Is Atlassian?

What Is Atlassian?

Distributed workforces are commonplace in today’s manufacturing and IT worlds. More and more colleagues work remotely. Additionally, we use more data to drive decisions as the market competition increases. Alongside this, our businesses are expected to meet...