We hear the terms "CI" and "CD" thrown around a lot these days, and I've worked on many projects that have implemented a CI/CD pipeline, some large with low user counts, some small with large user counts, as well as everything in-between.

I've seen what works well and what doesn't.

With this experience, we've implemented a CI/CD pipeline at Health Place that provides us with all the benefits of Continuous Delivery, wrapped up in a simple yet elegant implementation.

The goal

Before we get into it, let's quickly address the reason behind all of this:

What is the purpose of the CI/CD pipeline?

As the literature states, the crux of the CI and CD pipeline is to automate as much of the process as possible in order to get committed code up to production.

The CI pipeline

The goals of the CI pipeline are to make sure that any code committed is fit for a release candidate (code that is fit for deployment to any environment).

So, what do we do?

1. Trigger a CI build from any commit pushed to origin.
2. Build our dev Docker images.
3. Run automated tests.
4. Build our prod Docker images.
5. Push a release to the CD pipeline.

Yes, "Flaky Feature Tests" are present... but there is a concrete plan to eradicate them. This may even make its way into another article.

Tech stack

We use GitHub Actions, GitHub Workflows, and Github Packages. It ties in nicely with GitHub being our VCS of choice, and most importantly: it's simple.

Simplicity and explicitness are key values we hold close.

The 5-minute build

One of the tenets to follow is to ensure builds in the CI pipeline are sub 10 minutes. At Health Place, we've managed to keep our builds at around 5 minutes (that's just enough for me to brew my morning coffee... and maybe a few seconds to take that first sip).

This allows for extremely rapid feedback to be informed when a build has failed, allowing our engineers to fix the problem and commit without ever having to twiddle their thumbs.

Humans shouldn't do machine things

Everyone at Health Place is a talented human. So why would we ever want to waste their time doing mundane tasks they don't want to do?

Well, we don't.

We automate them, leaving our talented people to do the things they find interesting, the things that humans are better than machines at doing.

That's why our unit tests, code style tests, feature tests, integration tests, and any other possible tests we decide to implement in the future are all automated.

That means reviews left on PR's have no mention of code style or test coverage but focus purely on the human aspect. Things such as: if there may have been a more elegant way of implementing this or some design pattern that could have been leveraged, etc.

The CD pipeline

The first thing to get out of the way (which I know you're all wondering): we mean "Continuous Delivery" when we talk about CD. Continuous Deployment is somewhere we'd like to get to, but for now, Continuous Delivery is where we're at.

The goal of the CD pipeline is to deploy a release pushed by the CI pipeline to the specified environment.

This is a single click-of-a-button affair that any of our engineers are trusted to do (Octopus Deploy is our tool of choice).

There's not much else to say about this, as it is supposed to be simple by nature.

There's scope to include further tests in the CD pipeline, such as deployment tests, smoke tests, canary deployments, etc.

We will be implementing these supplementary automations down the line.

The entire workflow

Let's take a step back. We've deep-dived into both our CI and CD pipeline, but now let's look at the entire workflow from commit to deployment:

1. An engineer creates short-lived feature branch based off of trunk/master/main for a ticket.
2. The engineer makes a commit and pushes it to origin.
3. The CI pipeline runs build.
   • If there's a failure, then the engineer is notified within 5 minutes.
4. the CI pipeline creates and publishes a release to the CD pipeline.
5. The release appears in the CD pipeline.
6. The engineer can now deploy this release with a single-click to any environment.

The summary

I hope this gave you a good insight into how a CI/CD pipeline can be effectively implemented into a project.

If you want to do some further reading into the topics covered in this article, I can highly recommend these books:

• Continuous Integration: Improving Software Quality and Reducing Risk
• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
• Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations

Get in touch

If you have any questions, comment below, and I'll get back to you.

And if you think you'd like to work somewhere like Health Place, then message me for a chat at matt@healthplace.io.

Photo by Quinten de Graaf on Unsplash