34
loading...
Continuous Delivery at Health Place
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.
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 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?
Yes, "Flaky Feature Tests" are present... but there is a concrete plan to eradicate them. This may even make its way into another article.
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.
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.
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 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.
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:
trunk/master/main for a ticket.- If there's a failure, then the engineer is notified within 5 minutes.
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:
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 [email protected].
Photo by Quinten de Graaf on Unsplash
34