SAFe Practice Tips Part 1: Continuous Integration

This is the first part of the SAFe Practice Tips blog series where I discuss continuous integration (CI), delivery and deployment, the differences between them, and also how they relate to one another. This blog will help enable a smooth continuous journey for your team. The first practice we discuss is continuous integration.

Defining terms

First of all, CI/CD is not one thing. When people start using the term “CI/CD” they are merging different things together, and while they are related (you can’t have CD without CI) they are quite different in scope. The CD acronym further complicates things by being ambiguous (see below).

So, let’s define the terms:

Continuous Integration (CI)

The process of building your main branch of software on a regular basis to ensure it integrates together. “Integrates” is ambiguous though – the more you put in to CI the more you get out of it, so other practices such as automated unit testing, static code analysis, frequency of check-in, and frequency of CI execution greatly enhance the process. We’ll refer to this as CI in this article.

Continuous Delivery (CD)

An approach to delivering software that encompasses not just the functionality but also the automated release of software. Teams practicing Continuous Delivery will consider the release process as part of their work so that the product is truly Potentially Shippable at the click of a button. We’ll refer to this as CDel in this article.

Continuous Deployment (also CD!)

An approach to delivering software that embraces test automation to the point where as long as the software passes all automated tests any change is automatically released to production. We’ll refer to this as CDep in this article.

Defining a roadmap

Now that we’ve defined the terms and seen how they relate to each other, where should you start?

It’s quite simple to define a roadmap – CI > CDel > CDep

You can’t do CDep without CDel and you can’t do CDel without CI.

Where do I start?

For teams at the start of their continuous journey, CI is the place to start and is quite straight-forward to implement.

The following are required for basic CI:

• Source code in version control, such as GIT or SVN
• A CI Server such as Jenkins (other CI servers are available)
• A build script that builds your code

You configure the CI server to pull your code from version control whenever it changes and run the build-script. It will report the results.

You can greatly enhance the value of your CI by adding the following:

• Unit tests (might affect your team practices!)
• Test coverage analysis
• Static code analysis
• Clear standards
• Frequent developer check-ins
• A fast build & test process (~10 minutes)
• Visible dashboards so everyone can see what’s happening
• Swarming – if CI fails, everyone stops and assists with resolution

The more you put into CI, the more you’ll get out of it and the better prepared your team will be to move on to Continuous Delivery.

I hope this blog post has helped to give you a better understanding of Continuous Integration and the benefits that fast feedback will bring to your team. Keep an eye out for the next blog in this series which will discuss Continuous Delivery.