CI-CD and Deployment

🚀 DevOps & Deployment: The Art of Shipping Code Safely

The Restaurant Kitchen Analogy 🍳

Imagine you own a busy restaurant. Every night, you want to serve delicious new dishes to your customers. But here’s the catch—you can’t just shut down the kitchen to try new recipes! Customers are eating right now.

That’s exactly what CI/CD and deployment strategies solve for software.

Your code is the recipe. Your servers are the kitchen. Your users are the hungry customers. And you need to keep serving while constantly improving the menu!

🔄 CI/CD Pipelines in Cloud

What Is It?

Think of a CI/CD pipeline like a magical conveyor belt in a toy factory.

1. CI (Continuous Integration) = Every time a worker adds a new piece, the toy gets checked immediately. Does it fit? Is it painted right? No waiting until the end!

2. CD (Continuous Delivery/Deployment) = Once the toy passes all checks, it automatically moves to the shipping department.

graph TD
    A["Developer writes code"] --> B["Push to Git"]
    B --> C["Automatic Tests Run"]
    C -->|Pass| D["Build Application"]
    C -->|Fail| E["Alert Developer"]
    D --> F["Deploy to Cloud"]
    F --> G["Users get new features!"]

Real-Life Example

Without CI/CD: You bake 100 cookies, then realize you forgot sugar in all of them. 😢

With CI/CD: You check the first cookie. Missing sugar? Fix it NOW before making 99 more!

Cloud CI/CD Tools

📚 GitOps Principles

What Is GitOps?

Imagine your bedroom has a magic rule book. Whatever you write in the book, your room automatically becomes that way!

Write “bed is made” → ✨ Bed makes itself. Write “toys are organized” → ✨ Toys jump into boxes.

GitOps works the same way. Your Git repository is the “rule book.” Whatever you put there, your servers automatically become.

The Three Magic Rules of GitOps

1. Git is the single source of truth 📖

   • Everything about your system lives in Git
   • Want to know what’s running? Check Git!

2. Declarative, not imperative 🎯

   • You describe WHAT you want, not HOW to do it
   • “I want 3 servers” vs “Create server 1, then server 2, then server 3”

3. Automatic sync 🔄

   • A robot constantly watches Git
   • When Git changes, servers update automatically!

graph TD
    A["Developer updates Git"] --> B["GitOps Agent detects change"]
    B --> C["Agent compares Git vs Running System"]
    C -->|Different| D["Agent updates system to match Git"]
    C -->|Same| E["No action needed"]
    D --> F["System matches Git perfectly!"]

Example

# This file in Git says:
replicas: 3  # I want 3 copies
image: myapp:v2.0  # Using version 2.0

The GitOps agent reads this and makes it happen. No manual clicking!

🎯 Deployment Strategies Overview

When you release new code, you have choices—like how to introduce a new ice cream flavor at your shop!

Let’s explore each one! 👇

💙💚 Blue-Green Deployment

The Story

You have two identical ice cream shops side by side.

• Blue shop is serving customers right now
• Green shop is empty and ready for the new menu

When the new menu is perfect, you simply redirect all customers to the green shop. If anything goes wrong, you point them back to blue!

graph TD
    subgraph Current
    A["Users"] --> B["Blue - Old Version"]
    end
    subgraph After Switch
    C["Users"] --> D["Green - New Version"]
    end
    B -.->|Backup| B
    D -.->|If problems| B

How It Works

1. Blue runs the current version (v1.0)
2. Deploy new version to Green (v2.0)
3. Test Green thoroughly
4. Switch traffic: Blue → Green
5. Green becomes the new “live”
6. Keep Blue as backup!

Example

# Before switch
Production Traffic → Blue (v1.0)

# Switch!
Production Traffic → Green (v2.0)

# Problem? Roll back instantly!
Production Traffic → Blue (v1.0)

Why It’s Awesome ✨

• Zero downtime - Users never see “site under maintenance”
• Instant rollback - One switch and you’re safe
• Test in production environment - Green is identical to Blue

🐤 Canary Deployment

The Story

Remember coal miners bringing canaries into mines? If the bird got sick, miners knew the air was bad and they should leave.

Canary deployment works the same way!

Send a tiny bit of traffic to the new version first. If users have problems, you know immediately—before everyone is affected!

graph TD
    A["All Users 100%"] --> B{Traffic Split}
    B -->|95%| C["Old Version - Safe"]
    B -->|5%| D["New Version - Canary"]
    D -->|Healthy?| E["Gradually increase to 100%"]
    D -->|Problems?| F["Roll back to Old"]

Step by Step

1. Deploy new version to small group (5% of users)
2. Watch carefully for errors
3. If healthy, increase to 10%, 25%, 50%…
4. Eventually reach 100%
5. If problems at ANY step, stop and rollback!

Example Numbers

Why It’s Awesome ✨

• Minimal blast radius - Only 5% affected if something breaks
• Real user testing - Not just test accounts
• Gradual confidence - You KNOW it works before going all-in

🧊 Immutable Deployments

The Story

Imagine building with LEGO blocks. Instead of changing pieces on your creation, you build a completely NEW creation each time.

Old creation stays untouched. New creation replaces it entirely.

Immutable means “cannot be changed.” Once deployed, you NEVER modify it. Want changes? Deploy something completely new!

Traditional vs Immutable

graph TD
    A["Need Update"] --> B{Which approach?}
    B -->|Traditional| C["Update Server In-Place"]
    C --> D["Hope nothing breaks!"]
    B -->|Immutable| E["Create New Server"]
    E --> F["Deploy New Server"]
    F --> G["Delete Old Server"]
    G --> H["Clean & Predictable!"]

Why It’s Awesome ✨

• No “works on my machine” problems - Every deploy is identical
• Easy rollback - Just switch back to old image
• No drift - Servers don’t slowly become different from each other

⏪ Rollback Procedures

The Story

Imagine you’re writing a story and you can press Ctrl+Z to undo any mistake. Rollback is Ctrl+Z for your software!

Something went wrong? Go back to the version that worked.

When to Rollback

Rollback Checklist

1. Detect the problem - Monitoring alerts you
2. Decide to rollback - Is it faster than fixing?
3. Execute rollback - Switch to previous version
4. Verify it’s fixed - Check metrics are normal
5. Investigate later - Why did it break?

graph TD
    A["Problem Detected!"] --> B{Severity?}
    B -->|Critical| C["Immediate Rollback"]
    B -->|Minor| D["Attempt Quick Fix"]
    D -->|Fixed| E["Monitor Closely"]
    D -->|Not Fixed| C
    C --> F["Previous Version Running"]
    F --> G["Post-mortem: Why did it break?"]

Example

# Oops! v2.0 has a bug!
Current: v2.0 (broken)

# Execute rollback
kubectl rollout undo deployment/myapp

# Ahh, much better
Current: v1.9 (working)

🚩 Feature Flags

The Story

Imagine a light switch for every new feature in your app. You can turn features ON or OFF without deploying new code!

• Want to test a feature with just your team? ✅ Switch ON for employees only
• Feature causing problems? ✅ Switch OFF instantly
• Want to slowly release? ✅ Switch ON for 10% of users

How Feature Flags Work

graph TD
    A["User Opens App"] --> B{Check Feature Flag}
    B -->|Flag ON| C["Show New Feature"]
    B -->|Flag OFF| D["Show Old Feature"]
    E["Admin Dashboard"] -->|Toggle| B

Types of Feature Flags

Example Code

if (featureFlags.isEnabled('newCheckout')) {
  showNewCheckoutPage();
} else {
  showOldCheckoutPage();
}

Why It’s Awesome ✨

• Deploy ≠ Release - Code can exist without being visible
• Instant rollback - Toggle OFF, no deploy needed
• Gradual rollout - Show to 1%, then 10%, then 100%
• A/B testing - Try two versions, see which wins

🎯 Putting It All Together

Here’s how these strategies work together in a real deployment:

graph TD
    A["Developer pushes code"] --> B["CI/CD Pipeline runs tests"]
    B --> C["GitOps agent detects change"]
    C --> D["Immutable image created"]
    D --> E{Deployment Strategy}
    E --> F["Blue-Green: Switch all traffic"]
    E --> G["Canary: Start with 5%"]
    F --> H{Problems?}
    G --> H
    H -->|Yes| I["Rollback or use Feature Flag"]
    H -->|No| J["Celebrate! 🎉"]

Real Scenario

1. You write code for a new feature
2. CI/CD pipeline tests it automatically
3. GitOps picks up the change from Git
4. Immutable image gets built fresh
5. Canary deployment sends 5% of traffic
6. Feature flag controls who sees it
7. Problem? Rollback or toggle flag OFF!
8. No problem? Gradually increase to 100%

🎓 Key Takeaways

🌟 You Did It!

You now understand how modern software reaches users safely! These aren’t just fancy words—they’re the tools that let companies like Netflix, Google, and Amazon update their apps thousands of times per day without anyone noticing.

Next time an app updates without you restarting it, you’ll know: somewhere, a CI/CD pipeline just ran, a canary deployment passed, and feature flags are controlling exactly what you see.

You’re now part of the club that understands how the magic works! 🎩✨