SO, you deployed a new feature and brought your service down. Beyond the usual questions regarding test suites and CI/CD checks, there are ways to mitigate the risk when rolling out a new feature. Here are a few of the most common:
Blue-Green Deployments
This is a very common deployment pattern. You run two nearly identical setups running side by side. We call them blue (current version) and green (release candidate), just to keep things simple. Only one of these setups is doing the heavy lifting at any given time. We use a router or load balancer to play traffic cop, deciding which setup gets the spotlight. If things go south in our new green setup, we change the router or load balancer to send all traffic to the trusty blue setup, and boom – crisis averted! Consider it a safety net while you try out the new feature.
Canary Release
Similar to Blue-Green but more risk averse. A canary release is like a sneak peek for new features. Instead of throwing everything out there for everyone at once, we pick a small bunch of users to test it out first. We keep an eye on how things go after we roll it out to this group. If anything goes wonky, we can fix it up before it becomes a big headache. Once we're sure it's not going to blow up, we give the green light to push it out to everyone else.
Rolling Blue-Green
A variation of Blue-Green where you slowly roll out the Green to a percentage of users, say 10%. If everything is running smoothly after a time, you increase the green load to 25% and so on. If at any time, you notice a problem; you simply switch everyone back to the blue version.
There are other unique deployment patterns and variations and there are some caveats to some of the above particularly when database migrations are part of the deployment.
Have a favorite deployment pattern not mentioned? Want to share your experience with any of these? Drop you comments below.
Thanks!
Top comments (0)