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

Continuous Integration Best Practices—Part 2

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:

Latest White Papers

Atlassian Cloud: Understanding Zero Trust Security

Atlassian Cloud: Understanding Zero Trust Security

Where To Start & Why It Matters What is the Atlassian Cloud Zero Trust Security model? Well, for decades, enterprise security controls were built to protect a large, single perimeter around a corporation. Often described as castle-and-moat security, This approach...

Related Resources

Top 6 Ways To Improve Your DevOps Journey

Top 6 Ways To Improve Your DevOps Journey

Knowing how to improve DevOps can be challenging. But, creating an integrated DevOps toolchain can set organizations apart from the rest. This is because having a well-defined business DevOps journey can reduce errors, improve collaboration and drastically increase...

Why Process Automation Is Critical For Engineering

Why Process Automation Is Critical For Engineering

Process automation releases your engineers for the work their brains are intended for. That work is creativity and problem-solving.  By implementing process automation, you improve the team’s morale. Firstly, they get more focus time for deep work and designing better...

CloudBees SDA:  Software Delivery Without Silos

CloudBees SDA:  Software Delivery Without Silos

Tired of missing deadlines, and only measuring performance of departments, but not of your entire software delivery organization? This blog will show you how CloudBees Software Delivery Automation (CloudBees SDA) can break down silos, drive DevOps mentality and...