What is DevOps and CI/CD?

The problem DevOps solves

The old way: silos

Traditionally, teams were separate:

Developers: Write code, throw it “over the wall” to operations.

Operations: Receive code, try to deploy it, deal with problems.

This created friction:

• “It works on my machine” vs. “It doesn’t work in production”
• Developers blaming ops for deployment problems
• Ops blaming devs for unstable code
• Slow, painful, risky releases
• Long gaps between deployments

The DevOps response

DevOps breaks down these silos:

• Shared responsibility: Devs and ops work together
• Automation: Manual processes become automated pipelines
• Fast feedback: Problems are caught early, not in production
• Continuous improvement: Iterative, incremental changes
• Measurement: Data-driven decisions about quality and speed

Core DevOps practices

Infrastructure as Code (IaC)

Define infrastructure in code, not by clicking around consoles:

# Terraform example
resource "aws_instance" "web" {
  ami           = "ami-12345678"
  instance_type = "t3.micro"
  
  tags = {
    Name = "web-server"
  }
}

Benefits:

• Infrastructure is version-controlled
• Changes are reviewable
• Environments are reproducible
• Drift is detectable

Tools: Terraform, Pulumi, CloudFormation, Ansible

Configuration management

Keep configuration consistent across servers:

• Install the same software
• Apply the same settings
• Manage users and permissions

Tools: Ansible, Chef, Puppet, SaltStack

Monitoring and observability

Know what’s happening in your systems:

• Metrics: Numbers over time (CPU, memory, request rate)
• Logs: Events that happened
• Traces: Request paths through services

Tools: Prometheus, Grafana, Datadog, Loki, Jaeger

Collaboration and communication

Technical practices enable cultural change:

• Shared dashboards
• Incident response as a team
• Blameless postmortems
• Shared on-call rotations (sometimes)

CI/CD: the automation backbone

Continuous Integration (CI)

Every code change triggers:

1. Build the application
2. Run automated tests
3. Check code quality (linting, security scans)
4. Report results

# GitHub Actions example
name: CI
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install
      - run: npm test
      - run: npm run lint

The rule: If tests fail, the build is “broken.” Fix it before merging.

Continuous Delivery (CD)

Code that passes CI is automatically prepared for deployment:

• Build deployable artifacts (containers, packages)
• Deploy to staging environments
• Run integration tests
• Make it ready for production with one click

Humans decide when to push to production.

Continuous Deployment

Code that passes all tests automatically deploys to production. No human approval needed for routine changes.

This requires:

• High test coverage
• Excellent monitoring
• Fast rollback capability
• Feature flags for risk mitigation

Code → CI → Tests Pass → Deploy to Production (automatic)

A typical CI/CD pipeline

┌──────────────────────────────────────────────────────────────────┐
│                         Developer Workflow                        │
│  ┌─────────┐   ┌────────┐   ┌─────────┐   ┌────────────────────┐ │
│  │  Write  │──▶│  Push  │──▶│  Pull   │──▶│      Merge to      │ │
│  │  Code   │   │to Repo │   │ Request │   │       Main         │ │
│  └─────────┘   └────────┘   └─────────┘   └────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌──────────────────────────────────────────────────────────────────┐
│                          CI Pipeline                              │
│  ┌─────────┐   ┌────────┐   ┌─────────┐   ┌────────────────────┐ │
│  │  Lint   │──▶│ Build  │──▶│  Test   │──▶│  Security Scan     │ │
│  └─────────┘   └────────┘   └─────────┘   └────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
                                │
                         Tests Pass?
                        /           \
                      Yes            No
                       │              │
                       ▼              ▼
┌──────────────────────────┐    ┌────────────────────┐
│       CD Pipeline        │    │   Stop & Fix       │
│  ┌────────────────────┐  │    └────────────────────┘
│  │  Build Container   │  │
│  └────────────────────┘  │
│           │              │
│           ▼              │
│  ┌────────────────────┐  │
│  │ Deploy to Staging  │  │
│  └────────────────────┘  │
│           │              │
│           ▼              │
│  ┌────────────────────┐  │
│  │ Integration Tests  │  │
│  └────────────────────┘  │
│           │              │
│           ▼              │
│  ┌────────────────────┐  │
│  │  Deploy to Prod    │  │
│  └────────────────────┘  │
└──────────────────────────┘

Common CI/CD tools

Hosted / SaaS

Self-hosted

For Kubernetes

• ArgoCD: GitOps deployments
• Flux: Alternative GitOps tool
• Tekton: Kubernetes-native CI/CD

GitOps: a modern approach

GitOps applies DevOps principles to deployment:

Core idea: Git is the source of truth for both code and infrastructure.

1. All configuration is in Git
2. Changes are made via pull requests
3. Automated systems sync Git state to production
4. Drift is detected and corrected

Git Repo (desired state)
        │
        ▼
┌─────────────────┐
│  GitOps Agent   │ (ArgoCD, Flux)
│   Watches Git   │
└─────────────────┘
        │
        ▼ (sync)
┌─────────────────┐
│  Kubernetes     │ (actual state)
└─────────────────┘

Benefits:

• Auditable history of all changes
• Easy rollback (revert the commit)
• Declarative, reproducible
• Developer-friendly (PRs for deployments)

DevOps metrics: DORA

The DevOps Research and Assessment (DORA) team identified four key metrics:

These metrics help teams measure and improve their DevOps practices.

Starting with CI/CD (for vibecoders)

Simplest setup: GitHub Actions

1. Create .github/workflows/ci.yml:

name: CI
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test

2. Push to GitHub
3. Tests run automatically on every push

Add deployment

Many platforms auto-deploy from GitHub:

• Vercel: Connect repo, deploys on push
• Railway: Connect repo, deploys on push
• Netlify: Connect repo, deploys on push

No pipeline configuration needed.

Grow complexity as needed

Start simple. Add complexity when you need it:

1. Basic CI (tests on push)
2. Auto-deploy to staging
3. Manual promotion to production
4. Automatic production deploys (when confident)
5. Advanced: canary deployments, feature flags

DevOps culture vs. DevOps tools

Tools alone don’t make DevOps. Culture does:

Culture: “We ship small changes frequently because it’s safer.” Tools: CI/CD enables this with automation.

Culture: “When there’s an incident, we learn from it without blame.” Tools: Monitoring, logging, and postmortem processes support this.

Culture: “Everyone is responsible for production stability.” Tools: Shared dashboards, on-call rotations, deployment access.

Buying tools without cultural change just adds complexity.

The DevOps engineer role

DevOps started as a philosophy, but now there are DevOps engineers—people who:

• Build and maintain CI/CD pipelines
• Manage infrastructure as code
• Set up monitoring and alerting
• Automate repetitive tasks
• Bridge the gap between dev and ops teams
• Sometimes called “Platform Engineers” or “SRE” (Site Reliability Engineer)

Whether you need dedicated DevOps people depends on your scale and complexity.

Further reading

• What are containers? : What CI/CD often builds and deploys
• What is Kubernetes? : Where many CD pipelines deploy to
• What is cloud-native? : The broader philosophy
• What is deployment? : The end goal of CI/CD
• What is testing? : The tests CI runs