CI/CD para dados

CI/CD para dados é o mesmo princípio do software: toda mudança passa por revisão e por testes automáticos antes de chegar a produção, e a implantação é um processo repetível. A diferença é que, além do código, há o dado, que muda sozinho.

As etapas

• Lint e formatação: ruff ou flake8 no Python, sqlfluff no SQL. Pega erro bobo antes de gastar cluster.
• Testes unitários: a lógica de transformação como função pura, testada com dados pequenos e conhecidos.
• Implantação em dev/homologação: o job sobe num ambiente isolado.
• Testes de integração e qualidade: roda sobre amostra realista e confere as regras (veja Qualidade de dados).
• Produção: a mesma definição, com outra configuração, implantada pelo pipeline (GitHub Actions, Azure DevOps, GitLab CI, Jenkins).

Transformação testável

O segredo é separar a regra do Spark: a função recebe dados e devolve dados.

def classificar(valor):
    if valor is None:
        return "sem valor"
    return "alto" if valor >= 500 else "baixo"

def test_classificar():
    assert classificar(None) == "sem valor"
    assert classificar(500) == "alto"
    assert classificar(499.99) == "baixo"

test_classificar()
print("testes ok")

testes ok

No PySpark, o mesmo teste com um DataFrame pequeno roda num SparkSession local dentro do pytest, sem cluster.

Databricks Asset Bundles

Um *bundle* descreve jobs, pipelines e configurações em YAML (databricks.yml), versionado junto com o código, com alvos por ambiente. O pipeline de CI valida e implanta:

bundle:
  name: medalhao
targets:
  dev:
    mode: development
    default: true
  prod:
    mode: production

A sequência no CI costuma ser databricks bundle validate, databricks bundle deploy -t dev, os testes, e databricks bundle deploy -t prod depois da aprovação.

• Produção roda com uma *service principal*, não com o usuário de quem fez o merge.
• Segredo vai no cofre (Azure Key Vault, secret scope), nunca no notebook nem no YAML.