Continuous integration (CI) and continuous deployment (CD) are key parts of the DevOps lifecycle.
By automating build, test, and deployment processes, organisations can cut the time (and elbow grease) required to release new features fast, and get their applications running in a stable and production-ready state.
Most will be familiar with the general idea of CI/CD, and how it fits in with the DevOps lifecycle, DevOps pipeline or however you want to split hairs; so, we thought we’d put together a handy list of best practices, so you can sense check your set-up, and see if there’s anywhere you’re going wrong.
It’s the little things!
1. Write clear commit messages when it comes to version control
One of the key principles of CI/CD is that nearly everything goes into version control.
This allows developers to work together on the same codebase and enables the CI/CD pipeline to automatically build, test and deploy the latest version of the code.
However, sloppy, overlong or obtuse commit messages can cause multi-day work pile-ups which could have been avoided with a few extra seconds on the keyboard.
A good rule of thumb is to lead with the why rather than the what. That way, everyone can see what a change is aimed at, rather than having to second guess.
2. Use the same build artefacts in each environment
Rebuilding software between environments is a good way to load up on inconsistencies.
Instead, build one environment-agnostic artefact and store it in an artefact repository like Nexus.
This means you have one version going all the way to production, which makes for a much more streamlined process.
3. Show some restraint when it comes to test automation
Automated tests are an essential part of the CI/CD pipeline; they help ensure that the code is correct, performs as expected and ultimately allow you to get out new features fast.
However, it’s possible to get swept up in the sheer joy of DevOps (we know we have, from time to time) and start trying to automate everything under the sun.
In general, try to only automate tests that:
- require repetitive actions with big data sets
- are prone to human error
- that need to use multiple data sets
- That span multiple builds
This isn’t a hardline list. But the point is, be careful what you automate.
4. Use feature flags
Feature flagging (also known as feature toggles) is a software technique that allows organisations to switch features on and off without deploying new code.
Essentially, features are wrapped in a programmatic flag or toggle (all very intuitive, we know) that works like an on/off switch.
This fine-grained, less risky and less cumbersome control allows for a style of experimentation that is a big boon in CI/CD.
5. Adopt a ‘shift left’ approach to monitoring
Monitoring is essential for ensuring the stability and performance of your applications in production.
And it’s involved in many of the other best practices in this list.
A ‘shift left’ approach really just means aiming to implement monitoring in pre-production environments.
You want to catch as many issues as you can before your product ends up in the hands of the user!
6. Use canary releases
Canary releases, as the same suggests, involve a tentative release to production, then making these changes available to a small percentage of users.
These users are your canaries in the coal mine.
From there, you can test performance and stability before rolling the changes out to a broader set.
7. Perform A/B testing
A/B testing is a technique for comparing two versions of an application, or two different approaches to a problem, to see which performs better.
In CI/CD, it’s possible to build A/B testing into releases to get a better overview of your change’s overall impact.
For more, see here.
8. Use chaos engineering
Chaos engineering is the practice of intentionally introducing failures and disruptions to an application or system to test its resilience and robustness.
It’s essentially stress testing for applications.
For a full breakdown, check out our thoughts here.
But the long and short of it is you use chaos engineering services like Chaos Monkey, Chaos Gorilla or Chaos Kong (you’ll have to read our deep dive to discover the simian connection) to randomly switch off and break bits of your app to see how it recovers (or doesn’t). If you need this service provided, any DevOps agency worth their salt is a good bet.
How we can help
Through our DevOps as a service offering, we regularly partner with household names to both build, support and consult on cutting-edge DevOps pipelines.
So whether you’re looking to build from scratch or just get some advice, you know where we are.
