*This post is part of the series ‘SAFe Practice Tips’, which aims to offer helpful advice to anyone using SAFe.
This is the first part to the CI/CD blog series where I discuss continuous integration, delivery & deployment, and the differences between them but also how they relate to one another. This blog will help with enabling a smooth continuous journey for your team. The first practice we discuss is Continuous integration.
Where do I start?
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 the automated release of software also. 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.
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.
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 of this series which will discuss Continuous Delivery
Don’t miss the next part of the CI/CD blog - sign up to blog notifications.
Want to build your knowledge on SAFe , why not check out one of our SAFe training courses.