Phase 3: CI/CD & Automation

Choosing the Right Strategy

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

Imagine you’ve built an amazing LEGO castle – it’s huge, and all your friends are playing with it every single day. Now, you have a brilliant new idea: a towering new wall or a fancy drawbridge! You want to add this awesome new feature, but here’s the tricky part: you can't just knock down the whole castle and build a new one from scratch, can you? That would stop the game and make everyone wait. Grown-ups in technology have the same challenge. They build important online games, websites, or apps that millions of people use. When they want to add a new feature or fix something, they need a smart "strategy" – a clever plan for how to put the new pieces in without breaking anything or stopping people from using it. It’s like deciding the best way to add that new drawbridge to your LEGO castle so the fun never stops while you make it even better.

Let's think about a few strategies for your castle. One way is like a "quick swap": you ask your friends to step away for just a moment, quickly take off an old wall, and snap on the new drawbridge. It's fast, but for a tiny moment, the castle isn't ready for play. Another way is like building a "twin castle": you secretly build a brand new, identical castle right next to the old one, but this new one already has the drawbridge. Once it’s perfect, you tell all your friends, "Hey, everyone! Move to the new castle now!" The old one is still there, just in case, but everyone instantly switches. That’s super smooth, but it means you needed twice as many LEGOs for a little while. A third option is a "secret test": maybe you’re not sure if the drawbridge will work. You could add just one small section of the drawbridge, and only let one or two trusted friends try it out. If they like it, you slowly add the rest for everyone. If it's wobbly, you can easily take that small piece off without bothering anyone else.

Just like choosing how to add to your LEGO castle depends on how important it is, how many LEGOs you have, and how much your friends mind waiting, grown-ups pick their strategies. For a simple internal tool, they might use the "quick swap" because a tiny pause isn't a big deal. But for a huge online game or shopping site, they must use a "twin castle" or "secret test" to make sure nobody ever stops playing or buying, even for a second. They weigh things like cost, risk, and how quickly changes are needed. So, when you see a big new update to your favorite game or website, you'll know that smart people thought really hard about the best strategy to get that new feature to you without any glitches or stops. This means they can always keep improving things and ensure you have the best experience possible! You're understanding how the digital world keeps running smoothly.

Choosing the right deployment strategy is less about finding a universally "best" option and more about aligning your deployment process with your specific application requirements, business goals, and risk tolerance. There's no one-size-all answer; instead, it's a dynamic decision based on factors like the criticality of your application, the impact of downtime, the frequency of releases, and your team's operational maturity. A simple internal tool might tolerate a brief outage during a traditional recreate deployment, whereas a high-traffic e-commerce platform demands zero downtime and robust rollback capabilities, pushing you towards strategies like Blue/Green or Canary deployments.

Consider the inherent trade-offs. Strategies like Blue/Green offer excellent rollback safety and near-zero downtime but require double the infrastructure resources during the deployment phase, increasing cost. Canary deployments allow for gradual rollouts to a small subset of users, mitigating risk by testing new features in a production environment before a full release, but they introduce complexity in traffic routing and monitoring. A/B testing, while often considered a feature-level strategy, can be combined with deployment strategies to validate user experience and business metrics, adding another layer of decision-making based on desired feedback loops.

The most practical approach is often to start with simpler strategies like a rolling update, which is generally sufficient for many applications and is built into orchestrators like Kubernetes. As your application grows in criticality, user base, or release cadence, you can then incrementally adopt more sophisticated strategies to address emerging needs for higher availability, reduced risk, or advanced feature validation. Key questions to ask yourself include: "What is the maximum acceptable downtime?", "How quickly do we need to rollback?", "How important is real-user testing before full rollout?", and "What is our budget for infrastructure overhead?". Your answers will guide you to the most suitable strategy.

Key Takeaways

  • No single "best" deployment strategy; choose based on application context and business needs.
  • Align your strategy with your application's criticality, risk tolerance, and desired outcomes.
  • Understand the trade-offs: complexity vs. cost vs. downtime vs. risk reduction.
  • Start with simpler strategies (e.g., rolling update) and evolve as your needs mature.
  • Key factors to consider include acceptable downtime, rollback speed, and the need for real-user validation.

Code Example

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate # Explicitly defining the chosen strategy
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-registry/my-app:v1.0.0 # This image will be updated during a rollout
        ports:
        - containerPort: 80

How this code works

This Kubernetes Deployment YAML defines how an application named my-app runs and updates gracefully. Its primary job is to ensure the application remains available even when new versions are deployed, by using a specific update strategy designed to prevent downtime.

The spec section details the application's desired state. replicas: 3 ensures three instances of the application run concurrently for high availability. The selector matches pods created by this deployment using app: my-app labels, specified again within the template for the actual pod definition. Crucially, the strategy block explicitly sets type: RollingUpdate, which tells Kubernetes to gradually replace old application instances (defined by image: my-registry/my-app:v1.0.0) with new ones during an update. maxUnavailable: 25% and maxSurge: 25% fine-tune this process, ensuring no more than 25% of pods are down and no more than 25% extra pods are created at any time. A subtle point is that RollingUpdate is the default strategy for Kubernetes Deployments; while explicitly stated here for clarity, omitting strategy altogether would still result in a rolling update with these exact maxUnavailable and maxSurge defaults.

Related Articles

Hand-picked reads to go deeper on deployment strategies.

Back to DevOps Engineer Roadmap