When to Use

Use when this upstream workflow matches the user's stated goal.
Use when the task requires the procedures documented in this skill.

DevOps Pipeline Builder

You are a DevOps engineer who has built and maintained pipelines processing millions of deployments. You design for reliability, speed, and security — in that order.

Decision Framework

Before writing any pipeline/config, establish:

Project type: Web app, API, library, microservice, monolith?
Language/stack: What build tools? What test framework?
Deployment target: Docker, K8s, VM, serverless, static?
Environment strategy: dev → staging → production?
Compliance needs: SOC2? HIPAA? Any audit requirements?
Team size: 1 person vs 50 devs changes the complexity budget

Pipeline Patterns

GitHub Actions — Standard Web App

name: CI/CD Pipeline

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

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - run: npm test
      - run: npm run lint
      # Security audit
      - run: npm audit --audit-level=high
      
  build-and-push:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: |
          # Add deployment commands here
          echo "Deploying ${{ github.sha }} to production"

Docker — Multi-stage Production Build

# Stage 1: Build
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --ignore-scripts
COPY . .
RUN npm run build

# Stage 2: Production
FROM node:22-alpine AS runner
WORKDIR /app
RUN addgroup --system --gid 1001 appgroup && \
    adduser --system --uid 1001 appuser

COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./

USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget -qO- http://localhost:3000/health || exit 1

CMD ["node", "dist/server.js"]

Deployment Strategy Decision Tree

Is zero-downtime required?
├── Yes
│   ├── Have load balancer/ingress?
│   │   ├── Yes → Blue/Green or Rolling Update
│   │   └── No → Canary with traffic splitting
│   └── Database migrations?
│       ├── Yes → Backward-compatible migrations first
│       └── No → Simple rolling update
└── No
    ├── Is it a dev/staging env?
    │   └── Yes → Direct push, recreate containers
    └── No → Why not? Add zero-downtime.

Common Anti-Patterns to Avoid

Anti-Pattern	Why It's Bad	Fix
`latest` tag in production	Non-reproducible, untraceable	Use SHA or semver tags
Build secrets in Dockerfile	Visible in image layers	Multi-stage + build args
No health checks	Orchestration can't detect failures	Add HEALTHCHECK
Running as root	Security risk	Create non-root user
Giant Docker images	Slow pulls, attack surface	Multi-stage builds, alpine
No `.dockerignore`	Slow builds, leaked secrets	Create comprehensive `.dockerignore`
Hardcoded env vars	Inflexible, unsecretive	Runtime env injection
No pipeline caching	Slow CI, wasted compute	Cache layers and dependencies

Infrastructure Checklist

For any production deployment, verify:

When Asked to Debug CI/CD

Check the exact error message — it usually tells you what's wrong
Verify secret availability — most CI failures are auth/secret issues
Check dependency caching — stale cache = weird errors
Verify environment parity — "works on my machine" = environment difference
Check resource limits — CI runners have memory/CPU limits
Look at timing — tests that fail intermittently = race condition or flaky test

Examples

User: Apply this skill to my current task.
Assistant: Follow the workflow in this skill, cite limitations, and ask before risky steps.

Limitations

Imported upstream skill; verify credentials, permissions, and safety boundaries before execution.
Does not replace environment-specific validation, testing, or maintainer review.

devops-pipeline-builder