Many organizations are optimizing their software delivery for CI/CD in order to achieve the promise of cloud, microservices and fast, frequent feature release to stay competitive. However, many are finding they have optimized even for continuous deployment but are still experiencing outages in production. Why should this be? The reason is that deployment and release are two separate technical acts. You can be regularly deploying to production, but still be doing rolling updates as part of your release process. That means big, risky releases that result in issues. It doesn’t have to be that way. There are better ways than big-bang releases, where ‘hope the release is successful’ is the best you can do. In this blog post, you’ll learn how you can rethink your release process to overcome “big bang” releases and ship features to customers safely and more frequently.
Confusing the terms deployment and release
One thing we notice is that a lot of IT professionals and vendors confuse the words “deploy” and “release” (this was a big topic last week for us at the Velocity conference). There is actually a big difference and a lot of IT professionals are not aware of this. Here at Vamp we believe that you need to think about “release” as an independent and most crucial step of your shipping process in order to deliver on great customer experience. In this post, we’ll explain the difference. So, let’s jump in!
A deploy or deployment includes all the technical activities that are needed to make a software system or feature available for use. Think of a fresh Docker container running in a pod on the Kubernetes cluster. The piece of software passed all checks and tests in your (CI/CD) pipeline, and is ready to receive traffic from production users, but it is not actually receiving any, yet. This part of the process is just to make sure that the new version is healthy and running smoothly. It takes care of all the technical checks and balances, without any of the risk incurred by serving actual production traffic. You can conclude that deploying a piece of software is a mundane and risk-free activity.
A release comes after a deployment and includes all the activities that are needed to move part of, or all, production traffic to the new version. All the risks and things that could go wrong - downtime, lost revenue, angry managers and customers - are related to the release, and not deploy, to production. You can conclude that releasing a piece of software is an exciting and pretty risky activity. It’s an activity that deserves more attention.
You have continuous deployment, but are still doing a rolling update
Then comes the moment when you have to push that all-defining ‘release’ button, and the new version starts to serve production traffic. It’s a nail-biting, nerve-wracking moment when the nervous release engineer redirects all production traffic to the new version. The reason that happens is that you might have continuous deployment, but you are still doing a rolling update or “big bang release” to production. So, what’s the alternative?
Expose your service to a small segment of users instead of all users
A good methodology to prevent “big bang” is canary releasing – that is, trickling in a small sub-segment of user traffic. Traffic can be incrementally directed at the new version, slowly increasing the load, while monitoring for any performance issues, transactional errors or code bugs. Starting out with a small segment of users (either a percentage based, or more complex selection of users; for instance, all logged-out users), the release is verified in production, without any of the impact of releasing it to all users immediately. This safeguards the quality of your code and minimizes the business impact should a release fail.
The smaller your releases, the safer
The smaller your releases, the better, faster and more flexible each release is. It's easier to know what goes wrong if there are only a few changes in each release, making it easier to fix. Moving to smaller and smaller atomic releases is a vital part of a more mature release approach.
Release Strategies are key
But manually baby-sitting each canary release, making arbitrary decisions that vary from release to release, also doesn’t provide you with a robust, reliable approach. Instead, it makes sense to codify these decisions into release policies that control the conditions around each release and execute each canary release using those policies in an automated, hands-off way.
That way, you know your releases will follow the exact same release process, using the same parameters to increase the roll-out or roll back of a failed release. A release automation engine uses policies you create to take decisions over for you, so you can comfortably make more use of your time, knowing that the new version will not negatively impact customer experience - even on a Friday night.
If you are interested in seeing how Vamp Cloud-Native Release Orchestration works, book a guided tour to see the implications for your frontend and backend, with or without your own containers!