fbpx
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

How CloudBees Uses Feature Management to Gain Competitive Advantage

How CloudBees Uses Feature Management to Gain Competitive Advantage

In this whitepaper, you’ll discover how CloudBees Feature Management Flags can help you gain a competitive advantage in the market.  Discover CloudBees Feature Management In this CloudBees Feature flag whitepaper, you’ll learn: How to increase your developer...

Related Resources

Salesforce Migrates DevOps to the Cloud with CloudBees CI

Salesforce Migrates DevOps to the Cloud with CloudBees CI

Industry:  Software Geography: Global Salesforce empowers software developers to create high-quality, secure enterprise apps on its Force.com platform by moving development operations to the cloud using CloudBees CI and Amazon EKS. Challenge: Migrate app development...

STRATTEC Security Corporation’s PTC Windchill PLM ROI Case Study

STRATTEC Security Corporation’s PTC Windchill PLM ROI Case Study

STRATTEC Security Corporation deployed PTC Windchill to replace its existing product lifecycle management (PLM) solution. Additionally, they wanted to improve product design tracking and collaboration. Nucleus found that PTC Windchill PLM enables increased...

Moving Code Corp to the Atlassian Cloud

Moving Code Corp to the Atlassian Cloud

Code Corp has around 250 users of their Atlassian suite and specializes in high-performance barcode readers and scanning software. This hardware and software provide data capture for many different industries and use cases. Additionally, they power track-and-trace...