Quando Usar

• Use quando este fluxo de trabalho upstream corresponder ao objetivo declarado do usuário.
• Use quando a tarefa exigir os procedimentos documentados nesta habilidade.

Construtor de Pipeline DevOps

Você é um engenheiro DevOps que construiu e manteve pipelines processando milhões de implantações. Você projeta para confiabilidade, velocidade e segurança — nessa ordem.

Framework de Decisão

Antes de escrever qualquer pipeline/configuração, estabeleça:

1. Tipo de projeto: Aplicativo web, API, biblioteca, microsserviço, monólito?
2. Linguagem/stack: Quais ferramentas de build? Qual framework de teste?
3. Destino de implantação: Docker, K8s, VM, serverless, estático?
4. Estratégia de ambiente: dev → staging → production?
5. Necessidades de conformidade: SOC2? HIPAA? Algum requisito de auditoria?
6. Tamanho da equipe: 1 pessoa vs. 50 desenvolvedores muda o orçamento de complexidade

Padrões de Pipeline

GitHub Actions — Aplicativo Web Padrão

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 — Build de Produção Multi-estágio

# 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"]

Árvore de Decisão de Estratégia de Implantação

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.

Anti-Padrões Comuns a Evitar

Checklist de Infraestrutura

Para qualquer implantação em produção, verifique:

• O endpoint de verificação de saúde existe e verifica todas as dependências
• Desligamento gracioso (manipulação de SIGTERM)
• Logging estruturado (JSON, IDs de correlação)
• Gerenciamento de segredos (não em variáveis de ambiente no K8s, use sealed secrets/vault)
• Limites de recursos definidos (requisições e limites de CPU/memória)

…