Why Continuous Integration and Delivery Is Important

This is part one in my series on Modern Software Development Practices. In the series, I plan to cover multiple ways in which software engineers can improve their software by improving their processes and practices, all of which I have learned and lived through my time as a Software Consultant at ThoughtWorks and experiences at my current job at a large retail company in Germany.

I was once working with a client on a Cloud-Migration Project. On the first day that I arrived at the office, towards the end of the day one of the senior engineers invited me to “watch” the deployment with them. I was excited… I had never heard of “watching” a deployment before and was looking forward to finding out what that meant.

It was breathtaking… in the worst possible way.

The company, let’s call them ABC Corp, had 16 instances of the same software, each as a different white label hosted on separate Linux machines in their data center. What I ended up watching (for 3 hours) was how the client remotely connected to each machine individually and did a “capistrano deploy”. For those unfamiliar, Capistrano is essentially a scripting tool which allows for remote execution of various tasks. The deployment process involved running multiple commands on each machine and then doing manual testing to make sure it worked.

The best part was that this developer and one other were the only two in the whole company who knew how to run the deployment, meaning they were forbidden from going on vacation at the same time. And if one of them was sick, the other had the responsibility all for themselves. This deployment process was done once every two weeks.

I went home that night and couldn’t sleep.

One of my favorite things to do at work has always been automating myself out of a job, as cliché as that sounds. I try my best to follow the mantra “Don’t do anything manually more than once”. Deployments are the first thing I believe every team should automate, and one of the first things we worked on at ABC Corp, using a build pipeline to implement Continuous Integration and Continuous Delivery. Here’s why:

Continuous Integration

Known in the industry as CI, Continuous Integration is a practice in which developers push, or integrate as the name implies, changes as frequently as possible to the main repository. This usually happens multiple times per day. On a high level, this allows developers to notice and pinpoint errors in code or functionality as quickly as possible.

The idea is simple:

• A developer commits code to a repository’s master branch
• A CI server detects the changes and pulls them.
• The CI server builds the changes and labels it.
• All unit, integration, and end to end tests are run against the build.
• If at any stage anything goes wrong, including a failing test, the pipeline will stop and the developers are notified of the failure.

This results in the team seeing the way the project reacts to every single commit regardless of size. When something goes wrong, you can see exactly which commit caused the failure, and likely, exactly which line of code did it. Continuous Integration is one of the absolute best ways to go about keeping your code changes as small as possible for which the DevOps movement advocates for rather than the big bang changes. It also implies that in the case of multiple environments (Development, Testing, Integration, Production, etc) that the environments are as similar to one another as possible.

Continuous Delivery

Known as CD, Continuous Delivery refers to automating the deployment of code which has successfully run through your test-suite.

“Essentially, it is the practice of releasing every good build to users” - Jez Humble

Implementation is as follows:

• As another step in a build pipeline, once the tests are green, take the build created and deploy it via an automated script to your various environments (Test Environment, Integration Environment, Production Environment, etc)
• As a final step in the pipeline, run smoke tests to make sure the deployment has gone smoothly
• Set up monitoring and alerting to notify developers of failures
• Any code which the user should not see yet can be hidden behind feature flags

Given that all of the changes deployed are individual commits, the deployments are low risk and cause less bugs, but it also means that you as a business can develop and deploy code very quickly and as often as you want. Pairing this with containerization (i.e. Docker, K8s), especially on a cloud platform, allows for very quick deployments and little to no downtime, meaning the team can deploy at any time of the day.

Why is this important?

When looking at the four key software development metrics, which, as defined in Accelerate , which I talked about here , are the only metrics that matter when measuring a Software Team’s performance and efficiency. Good CI / CD practices can substantially improve how a team measures up.

1. Lead Time : CI / CD allows a developer to finish writing code and deploy the change directly to a production environment where the user has access to it. This can happen within a few hours or even a few minutes when a team has good CI/CD practices.
2. Deployment Frequency : Quicker, smaller deployments mean that the team can, and will deploy more often, especially if deployment is nothing special. Remembering ABC Corp, imagine how much more willing the team was to deploy when all it required was the push of a button which anyone could do at any time. Across all of Amazon’s teams around the world, they deploy on average once every 11 seconds.
3. Mean Time to Recovery : Scenario — the team deploys a change which causes a break. Due to the team’s great CI/CD practices, the team knows exactly which change and even which lines caused the issue. 15 minutes later a fix has been developed and deployed to production.
4. Change Failure Rate : Small changes paired with the early and often integration of your services and the full running of your test suite means that breaking changes are detected before they get anywhere near production. All code that gets to the users has been tested. Only the hidden bugs that come up every blue moon are left.

Things to remember

When a team is trying to implement and live CI/CD practices, they have to remember a few things when developing.

• The number one priority in the team is to fix any broken pipeline builds
• Developers should be pushing often in order to prevent big bang changes
• Developers should test code before they push as to not break the build
• Going home with a broken build is not allowed

CI/CD can be a great tool for all software teams if used well. Nobody wants to spend multiple hours watching a script run after executing a “capistrano deploy” hoping nothing goes wrong when they can simply push code every day and rest assured they will be alerted in the off chance something goes wrong.

Developers should be solving problems, not doing mundane tasks which a computer can do for us.

You can use any one of the popular CI Servers ( Concourse , Jenkins , GoCD , Circle-CI , and many more) to help generate incredible results and let developers work on the hard problems while simultaneously increasing software resiliency.

CI/CD is one of the most straightforward steps one can take towards implementing modern software practices, so as Nike says:

Thanks for reading and keep a lookout for the next post in my series Modern Software Development Practices!

RESOURCES:

• Concourse (Tool) https://concourse-ci.org/
• Jenkins (Tool) http://jenkins.io
• GoCD (Tool) https://www.gocd.org/
• Circle-CI (Tool) https://circleci.com/
• DevOps Movement (Info) https://aws.amazon.com/devops/what-is-devops/
• Companies which do DevOps well (Info) https://techbeacon.com/devops/10-companies-killing-it-devops
• Gene Kim Book Summaries (Info) https://medium.com/swlh/software-development-practices-as-recommended-by-gene-kim-c6f6e952309f