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

Three Trends Are Transforming The Service Desk

Three Trends Are Transforming The Service Desk

Your IT service desk is about to change. Find out what's shaping the future. Three factors — enterprise service management (ESM), collaboration, and intelligent service management — are driving the transformation of the service desk. To better meet customers’ needs...

Related Resources

Extending CloudBees SDA Analytics

Extending CloudBees SDA Analytics

CloudBees SDA Analytics has more power than you think One of the main features of CloudBees SDA is CloudBees Analytics, powered by ElasticSearch. It’s a powerful tool for displaying continuous integration data and there are loads of useful metrics available from...

Is The IT Department Really “Dead?”

Is The IT Department Really “Dead?”

“It’s Time to Get Rid of the IT Department.”  That was the title of an opinion piece recently published in the Wall Street Journal.  Provocative?  Sure.  My answer to this is not “yes,” but many of the author’s points are valid.  The Same Old IT Department? No, the IT...

How To Add More Disk Space To Your Redhat Server Without Reformatting

How To Add More Disk Space To Your Redhat Server Without Reformatting

(Originally published in 2012, updated January 2022.) One of the common tasks for any system administrator is managing disk space on a server. A common question is how to increase disk space on a linux system. I won't go into a boring lecture on why managing disk...