general devops

CI/CD (CI/CD)

ci-cd devops automation deployment
Plain English

CI/CD automates the boring, error-prone parts of getting code from a developer’s laptop to production. When a developer pushes code, CI (Continuous Integration) automatically runs tests and checks to make sure nothing is broken. If everything passes, CD (Continuous Delivery/Deployment) automatically deploys the changes to production. Without CI/CD, deployments are manual, stressful, and happen infrequently. With CI/CD, teams can ship multiple times a day with confidence.

Technical Definition

Continuous Integration (CI): the practice of frequently merging code changes into a shared repository, where automated builds and tests validate each change. The goal is to detect integration issues early.

Continuous Delivery (CD): extends CI by automatically preparing code for release to production. Every change that passes CI is deployable, but a human triggers the actual deployment.

Continuous Deployment: extends Continuous Delivery by automatically deploying every change that passes the pipeline to production. No human intervention required.

Typical CI/CD pipeline stages:

  1. Source: triggered by git push, pull request, or merge
  2. Build: compile code, install dependencies, build artifacts (Docker images, binaries)
  3. Test: unit tests, integration tests, end-to-end tests, security scans (SAST, dependency audit)
  4. Quality gates: code coverage thresholds, linting, type checking
  5. Staging: deploy to a pre-production environment for smoke tests
  6. Production: deploy to production (blue-green, canary, or rolling update)
  7. Post-deploy: health checks, smoke tests, monitoring, automatic rollback on failure

Common platforms: GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Buildkite, Drone, ArgoCD (GitOps).

Key practices:

  • Fast feedback (< 10 minutes for CI)
  • Trunk-based development (short-lived branches)
  • Infrastructure as Code (reproducible environments)
  • Immutable artifacts (build once, deploy the same artifact everywhere)
  • Deployment strategies (blue-green, canary) for zero-downtime releases

GitHub Actions CI/CD pipeline 

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check
      - run: npm test -- --coverage
      - run: npm run build

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - name: Deploy to production
        run: |
          rsync -avz --delete dist/ deploy@server:/var/www/app/
        env:
          SSH_KEY: ${{ secrets.DEPLOY_KEY }}
In the Wild

CI/CD is non-negotiable for professional software teams. GitHub Actions is the most popular CI/CD platform for open-source and startup projects. Enterprise teams often use GitLab CI/CD, Jenkins, or cloud-native options (AWS CodePipeline, Azure DevOps). A well-built pipeline catches bugs before they reach production: linting catches style issues, type checking catches type errors, unit tests catch logic errors, integration tests catch system-level failures, and security scans (npm audit, Snyk, Semgrep) catch vulnerabilities. The BytesNation site itself deploys via Render, which builds and publishes on every push to main: that is a simple CD pipeline. GitOps tools like ArgoCD extend CD to Kubernetes by syncing cluster state with a Git repository, making the repo the single source of truth.

← Back to Dictionary