CI/CD Complete Guide - Continuous Integration & Deployment

🔄 What is CI/CD?

CI/CD stands for Continuous Integration / Continuous Delivery (or Deployment) - a set of practices that automate the software delivery process.

📝 Code

→

🔨 Build

→

🧪 Test

→

📦 Release

→

🚀 Deploy

Benefits of CI/CD

⚡ Speed

Deploy in minutes instead of days. Faster feedback on code changes. Reduce time to market.

🛡️ Quality

Catch bugs early (before production). Consistent testing on every change. Reduce human error.

🔄 Consistency

Same process every time. Reproducible builds. No "works on my machine" issues.

📊 Visibility

See build/test status at a glance. Track deployment history. Easy rollbacks.

🔧 Continuous Integration (CI)

Automatically build and test code every time someone pushes changes.

Developer A ──┐
              │     ┌─────────────────────────────────────┐
Developer B ──┼────▶│  Shared Repository (main branch)    │
              │     └─────────────────────────────────────┘
Developer C ──┘                    │
                                   ▼
                       ┌─────────────────────┐
                       │      CI Server      │
                       │   (GitHub Actions)  │
                       └─────────────────────┘
                                   │
                  ┌────────────────┼────────────────┐
                  ▼                ▼                ▼
            ┌─────────┐     ┌───────────┐    ┌───────────┐
            │  Build  │     │   Test    │    │   Lint    │
            └─────────┘     └───────────┘    └───────────┘
                                   │
                                   ▼
                            ✅ Pass / ❌ Fail

CI Key Practices

Practice	Description
Frequent commits	Integrate small changes often (daily or more)
Automated builds	Every push triggers a build
Automated tests	Unit, integration tests run automatically
Fast feedback	Know within minutes if something broke
Fix immediately	Broken build = top priority to fix

🚀 Continuous Delivery vs Deployment

There are TWO meanings of "CD":

📦 Continuous Delivery

Code is ALWAYS ready to deploy, but human MANUALLY approves and triggers production deploy.

Build → Test → Staging → [👤 Approval] → Production
                              │
                         Manual click

🤖 Continuous Deployment

Every change that passes tests goes to production AUTOMATICALLY. No human intervention needed.

Build → Test → Staging → Production
                  │           │
                  └───────────┘
                   Automatic!

Comparison

Aspect	Continuous Delivery	Continuous Deployment
Production deploy	Manual trigger	Automatic
Human approval	Required	Not required
Risk	Lower (human review)	Higher (need great tests)
Speed	Fast	Fastest
Best for	Regulated industries, banks	SaaS, web apps

📦 Pipeline Stages

A typical CI/CD pipeline has these stages:

1️⃣ Source

Code pushed to repository
Pull request opened
Triggers the pipeline

2️⃣ Build

Compile code
Install dependencies
Create build artifacts
Run linters

3️⃣ Test

Unit tests
Integration tests
E2E tests
Security scans

4️⃣ Deploy

Deploy to staging
Run smoke tests
Deploy to production
Monitor for issues

🛠️ Popular CI/CD Tools

Cloud-Based (Hosted)

Tool	Description
GitHub Actions	Built into GitHub, YAML config
GitLab CI/CD	Built into GitLab, .gitlab-ci.yml
CircleCI	Fast, Docker-first
Azure DevOps	Microsoft ecosystem

Self-Hosted

Tool	Description
Jenkins	Most flexible, plugin ecosystem
TeamCity	JetBrains, great for Java
Bamboo	Atlassian, integrates with Jira

GitHub Actions Example

# .github/workflows/ci.yml
name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Test
        run: npm test
      
      - name: Build
        run: npm run build

🎯 Deployment Strategies

Modern deployment is about controlling traffic flow across multiple servers, not just replacing files.

💡 Key Insight: Your app runs on MULTIPLE servers. A load balancer controls which servers receive traffic. Deployment strategies control HOW we update these servers.

🔄

Rolling Deployment

Update servers one by one while keeping the service running.

✅ Zero downtime
✅ Low infrastructure cost
❌ Slow rollback

🔵🟢

Blue-Green

Maintain two complete environments. Switch traffic instantly.

✅ Instant rollback
✅ Full testing before switch
❌ 2x infrastructure cost

🐤

Canary

Send small % of traffic to new version first. Gradually increase.

✅ Test with real traffic
✅ Gradual rollout
❌ More complex

🚩

Feature Flags

Deploy code, hide behind flags. Toggle at runtime.

✅ Instant enable/disable
✅ No deployment to toggle
❌ Code complexity

Rolling Deployment

STEP 1: All servers on v1.0
┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│  v1.0 ✓  │  │  v1.0 ✓  │  │  v1.0 ✓  │  │  v1.0 ✓  │
└──────────┘  └──────────┘  └──────────┘  └──────────┘

STEP 2: Update Server 1 (others still serving)
┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│ UPDATING │  │  v1.0 ✓  │  │  v1.0 ✓  │  │  v1.0 ✓  │
│  ↓ v2.0  │  │  serving │  │  serving │  │  serving │
└──────────┘  └──────────┘  └──────────┘  └──────────┘

STEP 3-4: Continue until all updated
┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│  v2.0 ✓  │  │  v2.0 ✓  │  │  v2.0 ✓  │  │  v2.0 ✓  │
└──────────┘  └──────────┘  └──────────┘  └──────────┘

Blue-Green Deployment

                    USERS
                      │
                      ▼
              ┌───────────────┐
              │ Load Balancer │
              │   (Switch)    │
              └───────────────┘
                      │
         ┌────────────┴────────────┐
         ▼                         ▼
┌─────────────────────┐   ┌─────────────────────┐
│   BLUE ENVIRONMENT  │   │  GREEN ENVIRONMENT  │
│       (v1.0)        │   │       (v2.0)        │
│                     │   │                     │
│     [LIVE] ◄────────│   │     [STANDBY]       │
└─────────────────────┘   └─────────────────────┘

SWITCH: Change load balancer config
        Blue becomes standby, Green becomes live
        INSTANT rollback: just switch back!

Canary Deployment

                    USERS (100%)
                      │
                      ▼
              ┌───────────────┐
              │ Load Balancer │
              │ (% routing)   │
              └───────────────┘
                      │
         ┌────────────┴────────────┐
         │                         │
    95% traffic               5% traffic
         ▼                         ▼
┌─────────────────────┐   ┌─────────────────────┐
│   STABLE (v1.0)     │   │   CANARY (v2.0)     │
│   8 servers         │   │   1 server          │
└─────────────────────┘   └─────────────────────┘

GRADUAL ROLLOUT:
Step 1:  5%  ← Test with small % of real users
Step 2: 25%  ← Looking good...
Step 3: 50%  ← Half and half
Step 4: 100% ← Full rollout!

🚩 Feature Flags

Deploy the same code to all servers, but hide new features behind runtime flags stored externally.

YOUR APP (deployed code)          FLAG SERVICE (external)
─────────────────────────         ─────────────────────────

┌─────────────────────┐          ┌─────────────────────┐
│                     │   HTTP   │                     │
│  if (flags.newUI)   │ ◄──────► │  Flag Dashboard     │
│    <NewUI />        │  fetch   │  ┌───────────────┐  │
│  else               │          │  │ newUI: true   │  │
│    <OldUI />        │          │  │ darkMode: 50% │  │
│                     │          │  │ betaAPI: off  │  │
└─────────────────────┘          │  └───────────────┘  │
                                 │                     │
Same deployed code!              │  Changed via UI     │
No redeployment needed!          │  (no deploy!)       │
                                 └─────────────────────┘

⚠️ Key Point: Feature flags are stored externally (not in code) and fetched at runtime. This is how you can toggle features without redeploying!

How It Works

1️⃣ App Startup

App fetches all flag values from Flag Service. Caches them locally.

2️⃣ Runtime Check

Code checks flag value from cache. Shows feature based on flag.

3️⃣ Real-time Updates

WebSocket or polling for updates. Flag changed? App updates immediately!

4️⃣ Toggle via Dashboard

Product manager toggles flag in UI. NO deployment needed!

Code Example

// Initialize flag service (external)
const flags = new FlagService({
  apiUrl: 'https://flags.mycompany.com/api',
  apiKey: 'your-api-key',
});

await flags.initialize();

// Use in component
function CheckoutPage() {
  // Value comes from EXTERNAL service, not code
  const showNewCheckout = flags.isEnabled('new-checkout');
  
  if (showNewCheckout) {
    return <NewCheckout />;
  }
  return <OldCheckout />;
}

Popular Feature Flag Services

Service	Description
LaunchDarkly	Industry leader, enterprise
Split.io	Experimentation focused
Flagsmith	Open source option
ConfigCat	Simple, affordable
Unleash	Open source, self-host

📊 Choosing the Right Strategy

Aspect	Rolling	Blue-Green	Canary	Feature Flags
Rollback Speed	Slow	Instant ✅	Fast	Instant ✅
Infrastructure Cost	Low ✅	High (2x)	Medium	Low ✅
Complexity	Low ✅	Medium	High	Medium
Real User Testing	Yes	No	Yes ✅	Yes ✅

When to Use What

🔄 Rolling

Best for: Simple apps, internal tools, cost-conscious, stateless services

Avoid: Breaking changes, need instant rollback

🔵🟢 Blue-Green

Best for: Critical systems, instant rollback needs, compliance

Avoid: Very large infra, frequent deploys

🐤 Canary

Best for: Large user base, real traffic testing, gradual rollout

Avoid: Small user base, simple internal tools

🚩 Feature Flags

Best for: A/B testing, trunk-based dev, beta programs

Avoid: Simple features, short-lived changes

Who Uses What

Company	Strategy	Notes
Netflix	Canary + Feature Flags	Automated canary analysis
Facebook	Feature Flags (Gatekeeper)	Everything behind flags
Amazon	Canary + One-box	Deploy to ONE server first
Google	Canary + Feature Flags	Multiple canarying levels
Banks	Blue-Green	Guaranteed rollback

✅ Best Practices

⚡ Pipeline

Keep builds fast (< 10 min)
Run tests in parallel
Fail fast (quick checks first)
Use caching
Environment parity

🚀 Deployment

Automate everything
Monitor deployments
Easy rollbacks (one click)
Security scanning
Notify on failure

🚩 Feature Flags

Clean up old flags
Use naming conventions
Document flags
Set expiration dates
Test both states

📌 Summary

Component	Description
CI	Merge frequently, automated build & test
CD (Delivery)	Always deployable, manual production trigger
CD (Deployment)	Fully automated to production
Rolling	Update servers one by one
Blue-Green	Two environments, instant switch
Canary	Gradual % rollout
Feature Flags	Runtime toggle, no deploy needed

🎯 Key Takeaway: Modern deployment is about controlling traffic flow, not just replacing files. Choose the strategy that matches your team's needs and risk tolerance.