CI/CD Pipelines — GitHub Actions, trunk-based e deployment seguro

Em 2020, o time de engenharia do Etsy publicou uma análise de seus 10.000 deploys por ano — cerca de 27 deploys por dia em produção. Não era caos: era o resultado de uma filosofia de entrega contínua que data de 2011, quando a empresa pioneirou o conceito de "deploy everything, anytime". O insight central: deploys frequentes são mais seguros que deploys raros, porque cada deploy é menor, o diff de mudança é menor, e quando algo dá errado o rollback é mais simples. A ansiedade em torno de deploys é sintoma de um processo ruim — não de risco inerente ao deploy em si.

CI/CD (Continuous Integration / Continuous Delivery) é o conjunto de práticas e ferramentas que tornam esse volume de deploys possível e seguro. Mas CI/CD sem as práticas de engenharia corretas é automação de caos: se o código tem branches de longa duração, testes lentos ou ausentes, e deploys manuais, automatizar esse processo só acelera os problemas.

Trunk-based development — o pré-requisito

CI/CD real — onde cada commit no branch principal pode ir para produção — requer que o time trabalhe em trunk-based development (TBD): todos os desenvolvedores integram commits pequenos e frequentes diretamente ao branch principal (main), com branches de curta duração (horas, não dias).

O argumento contra TBD é "e features incompletas?". A resposta é feature flags: o código entra em produção, mas a feature está desabilitada para usuários até estar pronta. O código fica integrado, testado, e sem conflitos de merge — a feature é ativada por configuração quando estiver completa.

Branching de longa duração (GitFlow com release branches, develop branch) cria os problemas que CI/CD supostamente resolve:

• Merge conflicts acumulados por dias de trabalho divergente
• Integração de código acontece tarde — problemas são descobertos tarde
• O branch de release vira um buffer de risco, não uma garantia de qualidade
• Deploys raramente — cada deploy carrega mudanças de semanas

GitHub Actions — estrutura completa

GitHub Actions é baseado em workflows YAML que definem quando rodar (on), quais jobs executar (jobs), e os steps de cada job. Um pipeline completo para um serviço containerizado:

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

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

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

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.22'
          cache: true

      - name: Lint
        uses: golangci/golangci-lint-action@v6
        with:
          version: latest

      - name: Test com cobertura
        run: go test -race -coverprofile=coverage.out ./...

      - name: Upload cobertura
        uses: codecov/codecov-action@v4
        with:
          files: ./coverage.out

  sast:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - name: CodeQL Analysis
        uses: github/codeql-action/analyze@v3
        with:
          languages: go

  build-and-push:
    needs: [lint-and-test, sast]
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    permissions:
      contents: read
      packages: write
      id-token: write    # para OIDC cloud auth
    outputs:
      image-digest: ${{ steps.build.outputs.digest }}
    steps:
      - uses: actions/checkout@v4

      - name: Login no GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build e push com digest
        id: build
        uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

      - name: Assinar imagem com Cosign (Sigstore)
        uses: sigstore/cosign-installer@v3
        run: |
          cosign sign --yes \
            ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

OIDC para autenticação cloud — sem chaves permanentes

O padrão de armazenar AWS access keys ou GCP service account JSON como secrets no repositório é um risco de segurança conhecido: se o repositório vazar, as chaves vazam. O padrão moderno usa OIDC (OpenID Connect) para autenticação federada:

1. O GitHub Actions emite um JWT OIDC assinado pelo GitHub para cada job
2. A AWS (ou GCP/Azure) valida o JWT contra o OIDC provider do GitHub
3. Se válido, assume a IAM role configurada e emite credenciais temporárias
4. As credenciais expiram ao fim do job — nunca ficam armazenadas

# IAM Role Trust Policy (Terraform) para OIDC com GitHub Actions
resource "aws_iam_role" "github_actions" {
  name = "github-actions-deploy"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = "arn:aws:iam::${var.account_id}:oidc-provider/token.actions.githubusercontent.com"
      }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
        }
        StringLike = {
          # Restringir ao repositório e branch específicos
          "token.actions.githubusercontent.com:sub" = "repo:minha-org/meu-repo:ref:refs/heads/main"
        }
      }
    }]
  })
}

# No workflow GitHub Actions
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789:role/github-actions-deploy
    aws-region: us-east-1

Environments e aprovação manual

GitHub Environments permitem configurar regras de proteção para deploys — como aprovação manual de um reviewer antes de aplicar a produção:

jobs:
  deploy-staging:
    environment: staging   # sem proteção — deploy automático
    steps: [...]

  deploy-prod:
    needs: deploy-staging
    environment: producao   # configurado com required reviewers no GitHub UI
    steps:
      - name: Deploy para produção
        run: kubectl set image deployment/meu-app meu-app=ghcr.io/...${{ needs.build.outputs.image-digest }}

O workflow pausa no job deploy-prod até que um reviewer aprove no GitHub UI. Isso cria uma barreira humana para produção sem quebrar a automação do restante do pipeline.

Feature flags como substituto de branches de release

Feature flags (também chamados feature toggles) permitem que código incompleto entre em produção mas fique inativo para usuários. Existem vários tipos:

• Release toggle: habilita a feature para todos quando estiver pronta
• Experiment toggle: A/B test — mostra para X% dos usuários
• Ops toggle: desabilita feature durante incidente sem deploy
• Permission toggle: habilita para usuários beta ou premium

// Go — integração simples com LaunchDarkly
import "github.com/launchdarkly/go-server-sdk/v7"

func handleCheckout(user User) {
    flagValue, _ := ldClient.BoolVariation("nova-pagina-checkout", user.ToLDContext(), false)
    if flagValue {
        return renderNovaCheckout(user)
    }
    return renderCheckoutAntigo(user)
}

Feature flags introduzem dívida técnica se não forem removidos após a feature estar completamente deployed. A regra é: cada feature flag tem um ticket de limpeza criado junto com ela, com data de expiração. Flags antigas são mais perigosos que bugs — eles tornam o código impossível de entender.

Pipeline de segurança — SAST, dependency scan e container scan

Um pipeline de qualidade para produção inclui etapas além de testes:

# Exemplo de pipeline de segurança completo
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # SAST — análise estática do código fonte
      - name: Semgrep SAST
        uses: semgrep/semgrep-action@v1
        with:
          config: p/golang p/owasp-top-ten

      # Dependency scan — vulnerabilidades em bibliotecas
      - name: Govulncheck
        run: |
          go install golang.org/x/vuln/cmd/govulncheck@latest
          govulncheck ./...

      # Container scan — vulnerabilidades na imagem
      - name: Trivy scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'ghcr.io/${{ github.repository }}:${{ github.sha }}'
          exit-code: '1'    # falha o pipeline se houver HIGH ou CRITICAL
          severity: 'HIGH,CRITICAL'

DORA metrics — medindo a saúde do pipeline

O DORA Research Program (DevOps Research and Assessment) identificou quatro métricas que discriminam times de alta performance de times de baixa performance:

Esses números são contraintuitivos: times que fazem mais deploys têm menor change failure rate — não maior. A relação causal é que deployers frequentes têm deploys menores, que têm menos superfície de erro, e que são mais fáceis de rollback quando falham.

Lead time para changes é o tempo desde o commit até estar em produção. Um lead time de semanas indica branches de longa duração, processo de review lento, ou pipeline manual. Um lead time de horas indica TBD com CI/CD automatizado.

Decisões de engenharia

Perguntas de entrevista

Exercícios práticos