ci-cd-pipelines

When this skill is activated, always start your first response with the 🧢 emoji.

CI/CD Pipelines

A practitioner's guide to continuous integration and continuous delivery for production systems. This skill covers pipeline design, GitHub Actions workflows, deployment strategies, and the operational patterns that keep software shipping safely at speed. The emphasis is on when to apply each pattern and why it matters, not just the YAML syntax.

CI/CD is not a tool configuration problem - it is a software delivery discipline. The pipeline is the product team's contract with production: every commit that passes is a candidate release, and the pipeline enforces that contract automatically.

When to use this skill

Trigger this skill when the user:

• Creates or modifies a GitHub Actions, GitLab CI, or Jenkins pipeline
• Implements PR checks, branch protection rules, or required status checks
• Sets up deployment environments (staging, production) with promotion gates
• Implements blue-green, canary, rolling, or recreate deployment strategies
• Configures caching for dependencies or build artifacts to speed up pipelines
• Sets up matrix builds to test across multiple Node versions or operating systems
• Automates secrets injection, environment promotion, or rollback procedures
• Diagnoses a slow pipeline and needs to find what to parallelize or cache

Do NOT trigger this skill for:

• Infrastructure provisioning from scratch (use a Terraform/Kubernetes skill instead)
• Application-level testing strategies unrelated to pipeline structure

Key principles

1. Fail fast - The pipeline should surface errors as early as possible.

Run linting and type-checking before tests. Run unit tests before integration tests. A 30-second lint failure beats a 10-minute test run that tells you the same thing.

1. Cache aggressively - node_modules, Maven .m2, pip wheels, and Docker

layer caches can turn a 12-minute pipeline into a 3-minute one. Cache by the lockfile hash so the cache busts exactly when dependencies change.

1. Keep pipelines under 10 minutes - Pipelines longer than 10 minutes cause

developers to stop watching them, batch commits to avoid waiting, and skip running them locally. Parallelize jobs, split slow test suites, and move heavy analysis to scheduled runs.

1. Trunk-based development - Short-lived branches merged frequently (at

least daily) are the prerequisite for effective CI. Long-lived branches turn CI into a lie - the code integrates in CI but not in reality.

1. Immutable artifacts - Build once, deploy everywhere. The same Docker

image or archive that passed staging must be the thing that goes to production. Never rebuild from source at deploy time.

Core concepts

Pipeline stages run in order and each must pass before the next begins:

build -> test -> deploy:staging -> approve -> deploy:production

Triggers determine when a pipeline runs:

• push on any branch - run build and test
• pull_request - run full check suite for the PR
• schedule (cron) - run security scans or long test suites nightly
• workflow_dispatch - manual trigger with optional inputs for on-demand deploys

Environments are named targets (staging, production) with their own secrets, protection rules, and deployment history. GitHub Environments let you require manual approvals before promoting to production.

Secrets management - secrets live in GitHub Secrets or an external vault (Vault, AWS Secrets Manager). They are injected as environment variables at runtime. Never print them in logs. Rotate them on a schedule.

Artifact storage - build outputs (compiled code, Docker images, test reports) are stored in GitHub Artifacts or a registry (GHCR, ECR, Docker Hub). Artifacts have a retention window; images are tagged with the commit SHA.

Common tasks

Set up GitHub Actions for Node.js

A standard Node.js pipeline with lint, test, and build, using dependency caching:

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

on:
  push:
    branches: [main]
  pull_request:

jobs:
  ci:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm            # caches ~/.npm by package-lock.json hash

      - run: npm ci             # clean install from lockfile

      - run: npm run lint

      - run: npm test -- --coverage

      - run: npm run build

      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/
          retention-days: 7

Use npm ci instead of npm install in CI. It is faster, deterministic,

and will fail if package-lock.json is out of sync with package.json.

Implement PR checks

Require the CI workflow to pass before merging. Configure in GitHub Settings > Branches > Branch protection rules:

• Enable "Require status checks to pass before merging"
• Add the job name (ci) as a required check
• Enable "Require branches to be up to date before merging"

# .github/workflows/pr-check.yml
name: PR Check

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  lint:
    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

  test:
    runs-on: ubuntu-latest
    needs: lint           # only run tests if lint passes
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm test

  typecheck:
    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 typecheck

Set up deployment environments with approvals

Use GitHub Environments to gate production deploys behind a manual approval:

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image-tag: ${{ steps.tag.outputs.tag }}
    steps:
      - uses: actions/checkout@v4
      - id: tag
        run: echo "tag=${{ github.sha }}" >> $GITHUB_OUTPUT
      - run: docker build -t myapp:${{ github.sha }} .
      - run: docker push ghcr.io/org/myapp:${{ github.sha }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    environment: staging        # uses staging secrets + URL
    steps:
      - run: ./scripts/deploy.sh
        env:
          IMAGE_TAG: ${{ needs.build.outputs.image-tag }}
          DEPLOY_URL: ${{ vars.DEPLOY_URL }}
          API_KEY: ${{ secrets.DEPLOY_API_KEY }}

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production     # requires manual approval in GitHub UI
    steps:
      - run: ./scripts/deploy.sh
        env:
          IMAGE_TAG: ${{ needs.build.outputs.image-tag }}
          DEPLOY_URL: ${{ vars.DEPLOY_URL }}
          API_KEY: ${{ secrets.DEPLOY_API_KEY }}

Configure environment protection rules in GitHub Settings > Environments > production > Required reviewers.

Implement blue-green deployment

Route traffic between two identical environments. Switch instantly; roll back by switching back:

  deploy-blue-green:
    runs-on: ubuntu-latest
    environment: production
    env:
      IMAGE_TAG: ${{ needs.build.outputs.image-tag }}
    steps:
      - uses: actions/checkout@v4

      - name: Determine inactive slot
        id: slot
        run: |
          ACTIVE=$(curl -s https://api.example.com/active-slot)
          if [ "$ACTIVE" = "blue" ]; then
            echo "target=green" >> $GITHUB_OUTPUT
          else