Deployment & DevOps

Real-world analogy

What is it?

Deployment is the process of getting your code from your laptop to a server where users can access it. DevOps practices (CI/CD, containers, monitoring) make this reliable, repeatable, and automated.

Real-world relevance

Netflix deploys thousands of times per day. Amazon deploys every 11.7 seconds. Modern CI/CD pipelines make this possible — push code, let the robots handle the rest.

Key points

• CI/CD Pipeline — Continuous Integration and Continuous Deployment automates your entire workflow: push code to Git, automated tests run, linting checks pass, and if everything succeeds, the app deploys automatically to production. No manual steps, no human error. GitHub Actions, GitLab CI, and CircleCI are popular CI/CD platforms.
• Environment Variables — Each deployment environment (development, staging, production) needs different configuration: database URLs, API keys, feature flags, and log levels. Store these as environment variables, never hardcode them. Your CI/CD platform injects the right values for each environment automatically during deployment.
• Container Orchestration — Docker Compose manages multi-container apps on a single server. For larger scale, Kubernetes orchestrates containers across many servers: auto-scaling when traffic spikes, restarting crashed containers, rolling out updates with zero downtime. Start with Docker Compose and graduate to Kubernetes when your app demands it.
• Monitoring & Logging — Production apps need observability: structured logging with tools like Winston or Pino, error tracking with Sentry, performance monitoring with Datadog or New Relic, and uptime monitoring with Pingdom. If something breaks at 3 AM, automated alerts notify your team immediately via Slack, email, or PagerDuty.
• Scaling — When traffic grows beyond what one server can handle, scale horizontally by adding more instances behind a load balancer. The load balancer distributes incoming requests across all instances evenly. Make your app stateless (store sessions in Redis, files in S3) so any instance can handle any request interchangeably.
• SSL/HTTPS — Secure Your App — Production apps MUST use HTTPS to encrypt data in transit. Use Let's Encrypt for free SSL certificates, or your cloud provider's certificate manager. Never transmit passwords or tokens over plain HTTP — it's like sending postcards instead of sealed letters.
• Secrets Management — Never hardcode API keys or passwords in your code. Use environment variables (.env files locally, secret managers in production). Tools like AWS Secrets Manager, HashiCorp Vault, or even GitHub Secrets keep your sensitive data safe and separate from code.
• Blue-Green & Canary Deployments — Blue-green deployment runs two identical environments: blue (current) and green (new version). Switch traffic to green once verified. Canary deployment routes a small percentage of traffic (like 5%) to the new version first, then gradually increases. Both strategies minimize risk and enable instant rollback if issues arise.
• Infrastructure as Code — Define your servers, databases, and networking in code files (Terraform, Pulumi, or AWS CDK) instead of clicking through cloud consoles. Version control your infrastructure alongside your application code. Recreate entire environments from scratch with a single command — reproducible, auditable, and disaster-proof.

Code example

# 1. GitHub Actions CI/CD 🤖
# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: pnpm install
      - run: pnpm test
      - run: pnpm build

  deploy:
    needs: test  # Only deploy if tests pass!
    runs-on: ubuntu-latest
    steps:
      - run: docker build -t myapp .
      - run: docker push myregistry/myapp
      - run: ssh server "docker pull && docker compose up -d"

# 2. Environment variables — never hardcode secrets! 🔐
# .env (NEVER commit this file!)
DATABASE_URL=mongodb://localhost:27017/myapp
JWT_SECRET=super-secret-key-change-in-production
REDIS_URL=redis://localhost:6379

// In NestJS — read env vars safely:
@Injectable()
export class AppConfigService {
  get databaseUrl(): string {
    return process.env.DATABASE_URL;
  }
}

// 3. Health check endpoint — monitoring calls this 🏥
@Controller('health')
export class HealthController {
  @Get()
  check() {
    return {
      status: 'ok',
      timestamp: new Date().toISOString(),
      uptime: process.uptime(),
      memory: process.memoryUsage(),
    };
  }
}

Line-by-line walkthrough

1. 1. 1. GitHub Actions CI/CD 🤖
2. 2. .github/workflows/deploy.yml
3. 3.
4. 4.
5. 5.
6. 6.
7. 7.
8. 8.
9. 9.
10. 10.
11. 11.
12. 12.
13. 13.
14. 14.
15. 15.
16. 16.
17. 17.
18. 18.
19. 19.
20. 20.
21. 21.
22. 22.
23. 23.
24. 24.
25. 25.
26. 26.
27. 27. 2. Environment variables — never hardcode secrets! 🔐
28. 28. .env (NEVER commit this file!)
29. 29.
30. 30.
31. 31.
32. 32.
33. 33. In NestJS:
34. 34. Decorator that adds metadata or behavior
35. 35. Exporting for use in other files
36. 36.
37. 37. Returning a value
38. 38. Closing block
39. 39. Closing block
40. 40.
41. 41. 3. Health check endpoint 🏥
42. 42. Decorator that adds metadata or behavior
43. 43. Exporting for use in other files
44. 44. Decorator that adds metadata or behavior
45. 45.
46. 46. Returning a value
47. 47.
48. 48.
49. 49.
50. 50.
51. 51. Closing block
52. 52. Closing block
53. 53. Closing block

Spot the bug

const app = await NestFactory.create(AppModule);
app.listen(3000);
console.log("Running on port 3000");

Explain like I'm 5

Fun fact

Hands-on challenge

More resources

• Vercel Documentation (Vercel Official)
• GitHub Actions Documentation (GitHub Official)
• CI/CD in 100 Seconds (Fireship)