What does a continuous delivery pipeline look like? Which pieces do we need to have in place for us to achieve true continuous delivery? Kamalika Majumder lays out the anatomy of a continuous delivery pipeline.
What Companies NeedCompanies are always looking for
In essence, they want to sell faster and sell better quality products. This applies to all companies, whether they’re selling services or actual products.
Most companies use many different DevOps tools, but don’t have the results to show for it because:
Why do we still see these issues a decade after DevOps gained traction?
Everyone needs one single pipeline for the application lifecycle management and continuous delivery of quality products. This includes:
This all needs to be linked together into one single pipeline. Today, we’ll focus on the basics of a continuous delivery pipeline.
Martin Fowler defined continuous delivery as
“a discipline where you build software in such a way that the software can be released to production at any time.”
It’s important to stress that your code is always deployable. This means continuous delivery is a cycle of five principles:
During development, merging code can lead to merge conflicts. This is a frustrating experience. This is caused by waiting too long to merge your changes back into the master branch. You need to keep your code updated, shortening the feedback cycle.
Trunk based development solves this issue. Temporary branches are okay for features, and short-lived release branches are fine. But everyone should commit to the master branch regularly (once a day!).
If you have unfinished code, hide it with feature toggles instead of keeping a branch open for too long.
Keep your master branch in a releasable state and never add to a broken master branch.
We’re still seeing “it works on my machine” issues.
We should build our artifacts once and deploy multiple times. We should version our artifacts (using semantic versioning). And this means all our artifacts: applications, configuration, database scripts, etc. Automate all of this in a pipeline.
Previously, many teams built their applications first and added tests later. This leads to many manual tests and UI tests. This is a slow and error-prone process. It’s better to start from the bottom up using test driven development. Write your tests first. This leads to a shorter feedback cycle.
Then work your way “up” and automate each level: integration, API and UI tests. Don’t forget performance and security tests as well.
When something in the infrastructure changes, this can break things and then we often have a hard time finding the cause. Version controlling your infrastructure as code helps identify changes that were made to the infrastructure.
This also applies to configuration. If everything is in source control, you can easily see what changed and why.
When you have infrastructure and configuration as code, you can run automated tests against it. Just like you write unit tests for your code, you can write unit tests for infrastructure or configuration.
Then we can version this and run it through a continuous integration pipeline. This way, you can link application versions and configuration versions to what is running in production.
Finally, look at zero downtime deployments. In this day and age, you should be able to update your system without downtime.
Avoid having one deployment team. If your deployment pipeline is configured correctly, with the correct access rights, anyone from the development team can deploy to production.
Once you’re running your application, make sure you have robust monitoring, logging and alerting:
This is useful to improve your continuous delivery cycle over time.
And always have a plan B. If something goes horribly wrong, make sure you can perform a rollback.
You can check out Kamalika Majumder’s full All Day DevOps talk “Anatomy of a Continuous Delivery Pipeline” here.