Como configurei meu primeiro pipeline de CI/CD — e o que aprendi no processo

Deploy às 23h.

SSH no servidor, git pull, restart. Funcionou. Fui dormir.

6h da manhã: cliente com ticket. Sistema estava retornando 500 desde meia-noite. O pull tinha trazido uma mudança que quebrava com os dados reais de produção — algo que não tinha aparecido nos testes que eu tinha rodado local.

Seis horas de sistema quebrado que eu não sabia, porque meu processo de deploy tinha zero verificação automática.

Comecei a aprender CI/CD nessa semana.

CI (Continuous Integration) é rodar testes automaticamente toda vez que alguém commita. CD (Continuous Delivery/Deployment) é deploy automático quando os testes passam.

O objetivo não é velocidade de deploy — é confiança. Você quer ter certeza que o que está sendo deployado não quebra o que já funcionava.

O primeiro pipeline que criei, com GitHub Actions:

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest
    
    services:
      postgres:
        image: postgres:13
        env:
          POSTGRES_PASSWORD: testpassword
          POSTGRES_DB: testdb
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-retries 5

    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
        with:
          python-version: '3.8'
      
      - name: Install dependencies
        run: pip install -r requirements.txt
      
      - name: Run tests
        env:
          DATABASE_URL: postgresql://postgres:testpassword@localhost:5432/testdb
        run: pytest tests/ -v

Simples. Mas já resolve o problema principal: nenhum código vai para produção sem passar nos testes.

O que aprendi durante a configuração:

Ambiente de CI não é o mesmo que ambiente local. Você vai descobrir dependências implícitas no seu sistema que não estavam no requirements.txt, ordem de operações que você fazia manualmente mas não estava automatizada. Isso é positivo — o CI te força a tornar o setup explícito.

Testes que dependem de estado externo quebram. Teste que chamava API real de terceiro passava local e falhava em CI (sem credenciais). Aprendi a mockar chamadas externas nos testes.

Pipeline lento desmotiva. Se CI demora 15 minutos, as pessoas param de esperar e mergem assim mesmo. Manter CI rápido (abaixo de 5 minutos para feedback inicial) é tão importante quanto manter CI funcionando.

A mudança que o pipeline trouxe não foi técnica — foi cultural.

Sem CI: "vou commitar e ver se funciona". Com CI: "vou commitar e o pipeline me diz se funciona".

Você para de ser o gatekeeper do próprio trabalho. O processo faz isso. E quando o pipeline quebra, você sabe imediatamente o que e onde, não seis horas depois quando o cliente abre ticket.

Desde 2020, não deployei manualmente nenhum sistema relevante. Não é dogmatismo — é que a alternativa já me custou uma noite de sono.