Phase 5: DevOps & Deployment

Deployment strategies: blue-green, canary & rolling

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you have built the most awesome, giant LEGO castle ever. It's super popular, and all your friends love playing with it every day. But like any great builder, you always have new ideas! Maybe you want to add a cool new drawbridge, or fix a wobbly tower. The big challenge is: how do you make these awesome changes without stopping anyone from playing, or accidentally breaking the whole castle? That's what "deployment strategies" are about – smart ways to update your creations!

One way is like a Rolling Update. Instead of taking the whole castle apart, you carefully pick one small section – maybe a single wall – and while friends are playing in other parts, you swap out old bricks for new, stronger, or cooler ones. You watch to make sure that new wall is solid and still fits perfectly. If it works, you move to the next small section, then the next. This way, the castle is always available, though some parts might be new while others are still old. It’s a good, safe way to update without too much interruption, but you have to be careful the old parts still work with the new parts.

Then there's the Blue-Green Update. This is like having two identical playrooms, each with its own full-sized castle. Everyone is playing with the "Blue" castle. In the other room, you secretly build a totally new, super-improved "Green" version. You add all the drawbridges, fix all the towers, and make sure it’s absolutely perfect. Once you’re certain the "Green" castle is ready, you shout, "Everyone, stop playing with Blue and come play with Green!" It’s an instant switch! All your friends immediately go to the new castle. If, by some chance, you discover a problem in the "Green" castle, you can instantly tell everyone, "Oops! Go back to the Blue castle!" while you fix the "Green" one.

Finally, a Canary Update is a bit more cautious. Imagine you've built a fantastic new secret passage. Instead of putting it on the main castle for everyone, you first let just one or two of your most trusted friends – your "canaries" – try out the new passage. They play with it, climb through it, and tell you if it's super sturdy or if it gets stuck. If your canary friends report it's awesome and stable, then you slowly add that secret passage to more and more parts of the big castle for everyone. This way, if there's a problem, only a few people ever notice, and you can fix it quietly before it becomes a big deal.

So, when you grow up and build your own amazing apps or websites, you'll use these ideas to update them smoothly, keeping everyone happy and making sure your creations are always improving without ever completely shutting down the fun!

As a full-stack developer managing CI/CD, understanding deployment strategies is crucial for delivering updates reliably. The simplest is Rolling Deployment, where new versions of your application are gradually rolled out, replacing old instances one by one or in small batches. Imagine updating a fleet of servers; instead of taking them all down, you update a few, check for issues, and then move to the next batch. This minimizes downtime and risk, as only a subset of users might encounter issues if something goes wrong. However, it means for a period, both old and new versions run concurrently, requiring careful attention to backward compatibility.

For applications requiring zero downtime and quick rollback, Blue-Green Deployment is a powerful option. You maintain two identical production environments: "Blue" (the currently active version serving live traffic) and "Green" (the new version, deployed and tested in parallel). Once the "Green" environment is fully validated, you simply switch the traffic router (e.g., a load balancer) to point from "Blue" to "Green". If any issues arise post-switch, you can instantly revert by switching traffic back to the "Blue" environment, which remains untouched. This offers maximum safety and minimal downtime but requires double the infrastructure resources during the deployment phase.

When you want to test new features or major changes with a small audience before a full rollout, Canary Deployment is your go-to. Similar to sending a canary into a mine to test the air, you release the new version to a small, controlled percentage of your users (e.g., 5% of traffic) while the majority still use the old version. You then meticulously monitor this "canary group" for errors, performance degradation, or unexpected behavior. If the canary proves stable, you gradually increase the traffic routed to the new version until it reaches 100%. This strategy significantly reduces the blast radius of potential problems, allowing you to catch issues early with minimal impact on your entire user base, making it ideal for high-stakes releases.

Key Takeaways

  • Rolling Deployments update instances gradually, minimizing downtime but allowing mixed versions temporarily.
  • Blue-Green Deployments involve two parallel environments (old/new); traffic is switched, offering instant rollback at the cost of double infrastructure.
  • Canary Deployments expose new features to a small user subset first, mitigating risk before a full rollout.
  • Choosing a strategy depends on your application's tolerance for downtime, risk, and available infrastructure.

Code Example

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate # Specifies the rolling update strategy
    rollingUpdate:
      maxSurge: 1       # Allows 1 extra pod during update
      maxUnavailable: 0 # Ensures 0 pods are unavailable
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: your-repo/my-app:v2.0 # New version image

How this code works

This code defines a Kubernetes Deployment that manages three instances of my-app. Its primary job within CI/CD is to perform a controlled update of the application to v2.0 without interrupting service. The spec.strategy.type: RollingUpdate explicitly tells Kubernetes to update pods incrementally. This approach avoids downtime by gradually replacing old application versions with new ones, rather than shutting everything down at once. The selector ensures the Deployment manages pods labeled app: my-app, while the template specifies the your-repo/my-app:v2.0 image for new pods.

The rollingUpdate configuration fine-tunes this process. maxSurge: 1 allows Kubernetes to create one extra new pod beyond the desired replicas count during the update. Crucially, maxUnavailable: 0 ensures that no existing application pods are terminated until the new ones are fully ready and available. This combination guarantees zero downtime: a new pod is always brought online before an old one is removed. A subtle aspect is that setting maxUnavailable to 0 alone would stall the update without maxSurge, as it wouldn't be able to remove an old pod without violating the 0 unavailability rule. maxSurge: 1 provides the capacity to add new pods first.

Resources

Related Articles

Hand-picked reads to go deeper on ci/cd pipelines.

Back to Full-Stack Developer Roadmap