Neste artigo você vai aprender

Neste artigo, você vai entender o que é CI/CD para engenharia de dados, por que essa prática se tornou essencial em projetos modernos de dados e como ela ajuda a reduzir erros, organizar pipelines e dar mais segurança para mudanças em ambientes como Databricks, Snowflake e dbt.

Você também vai ver exemplos práticos com GitHub Actions, dbt, Databricks Asset Bundles e Snowflake, além de boas práticas para começar de forma simples, segura e progressiva.

Sumário

O caos dos projetos de dados sem CI/CD

Todo projeto de dados começa simples: um notebook no Databricks, uma query SQL no Snowflake, uma tabela usada por um dashboard no Power BI, um modelo dbt criado para organizar uma camada de transformação ou um pipeline que roda todos os dias e alimenta uma área de negócio.

No início, tudo parece sob controle. O time é pequeno, poucas pessoas alteram os arquivos e as regras de negócio ainda são fáceis de lembrar. O problema aparece quando o projeto cresce.

Um analista altera uma query direto em produção para corrigir um número urgente. Um engenheiro muda uma transformação na camada Silver sem revisar todos os impactos. Um notebook é duplicado para “testar rápido” e depois ninguém sabe qual versão é a correta. Um script SQL fica salvo apenas na máquina de alguém. Um pipeline quebra de madrugada e ninguém sabe exatamente qual mudança causou o erro.

Problemas comuns sem CI/CD

• Notebooks alterados manualmente em produção.
• Scripts SQL sem versionamento.
• Pipelines quebrando sem aviso.
• Mudanças feitas direto no ambiente produtivo.
• Ausência de testes automáticos.
• Diferença entre desenvolvimento, homologação e produção.
• Dificuldade para descobrir quem alterou o quê.
• Retrabalho entre analistas, engenheiros e áreas de negócio.

O que é CI/CD?

CI/CD é um conjunto de práticas que permite validar, testar e publicar mudanças de forma mais segura e automatizada. A sigla vem de três conceitos principais: Continuous Integration, Continuous Delivery e Continuous Deployment.

Apesar de terem nascido no desenvolvimento de software, esses conceitos fazem cada vez mais sentido na engenharia de dados. Pipelines, notebooks, modelos dbt, scripts SQL e workflows também são código. E código precisa de versionamento, revisão, teste e deploy controlado.

CI/CD em software versus CI/CD em dados

Na engenharia de dados, o código não é o único ponto de atenção. Também existe o dado. Uma API pode estar funcionando tecnicamente, mas um pipeline de dados pode rodar sem erro e ainda assim gerar uma informação errada.

O ponto central: em engenharia de dados, não basta testar se o código executa. É preciso testar se o dado continua confiável.

Por que CI/CD é importante na engenharia de dados?

CI/CD é importante porque reduz o risco de mudanças mal controladas em pipelines que alimentam decisões reais. Quando uma empresa usa dados para acompanhar vendas, margem, estoque, churn, receita, inadimplência, produtividade ou qualquer outro indicador, ela precisa confiar no caminho que transforma dados brutos em informação útil.

Exemplos do dia a dia: onde CI/CD ajuda de verdade?

Como funciona um fluxo ideal de CI/CD para dados?

Um fluxo de CI/CD para dados pode variar conforme a empresa, as ferramentas e o nível de maturidade. Mesmo assim, uma estrutura segura costuma seguir uma sequência clara: desenvolvimento, Git, Pull Request, testes, staging, produção e monitoramento.

Estrutura de projeto recomendada

Uma estrutura bem organizada facilita CI/CD, revisão, testes e manutenção. O objetivo é evitar arquivos soltos e criar uma base previsível para o time trabalhar.

data-project/
│
├── notebooks/
│   ├── bronze/
│   ├── silver/
│   └── gold/
│
├── src/
│   ├── ingestion/
│   ├── transformations/
│   └── utils/
│
├── sql/
│   ├── migrations/
│   ├── procedures/
│   ├── tasks/
│   └── views/
│
├── dbt/
│   ├── models/
│   ├── tests/
│   ├── macros/
│   ├── seeds/
│   └── dbt_project.yml
│
├── tests/
│   ├── unit/
│   └── integration/
│
├── .github/
│   └── workflows/
│       ├── ci.yml
│       ├── dbt-ci.yml
│       └── deploy.yml
│
├── docs/
│   ├── architecture.md
│   ├── data-dictionary.md
│   └── business-rules.md
│
├── config/
│   ├── dev.yml
│   ├── staging.yml
│   └── prod.yml
│
├── README.md
└── requirements.txt

Exemplos com código

Exemplo 1: GitHub Actions genérico para validação

Este workflow instala dependências, valida a estrutura de pastas, executa lint em Python, YAML e SQL, além de rodar testes automatizados.

name: CI - Data Project

on:
  pull_request:
    branches:
      - main
  push:
    branches:
      - develop

jobs:
  validate:
    name: Validate project
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install ruff pytest yamllint sqlfluff

      - name: Validate folder structure
        run: |
          test -d src
          test -d sql
          test -d tests
          test -d docs

      - name: Lint Python code
        run: |
          ruff check src tests

      - name: Lint YAML files
        run: |
          yamllint .

      - name: Lint SQL files
        run: |
          sqlfluff lint sql --dialect snowflake

      - name: Run tests
        run: |
          pytest tests

Exemplo 2: CI/CD com dbt

Esse fluxo valida dependências, conexão, compilação, testes e execução dos modelos. Em projetos reais, use targets separados para dev, staging e prod.

name: CI - dbt

on:
  pull_request:
    branches:
      - main

jobs:
  dbt-ci:
    name: Validate dbt project
    runs-on: ubuntu-latest

    env:
      DBT_PROFILES_DIR: ./dbt

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install dbt
        run: |
          python -m pip install --upgrade pip
          pip install dbt-core dbt-snowflake

      - name: Install dbt dependencies
        working-directory: ./dbt
        run: |
          dbt deps

      - name: Validate dbt connection and setup
        working-directory: ./dbt
        env:
          SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
          SNOWFLAKE_USER: ${{ secrets.SNOWFLAKE_USER }}
          SNOWFLAKE_PASSWORD: ${{ secrets.SNOWFLAKE_PASSWORD }}
          SNOWFLAKE_ROLE: ${{ secrets.SNOWFLAKE_ROLE }}
          SNOWFLAKE_DATABASE: ${{ secrets.SNOWFLAKE_DATABASE }}
          SNOWFLAKE_WAREHOUSE: ${{ secrets.SNOWFLAKE_WAREHOUSE }}
          SNOWFLAKE_SCHEMA: ${{ secrets.SNOWFLAKE_SCHEMA }}
        run: |
          dbt debug

      - name: Compile dbt models
        working-directory: ./dbt
        run: |
          dbt compile

      - name: Run dbt tests
        working-directory: ./dbt
        run: |
          dbt test

      - name: Run dbt models in target environment
        working-directory: ./dbt
        run: |
          dbt run

Exemplo 3: CI/CD com Databricks

No Databricks, o projeto pode tratar jobs, notebooks, pipelines e configurações como código usando bundles e deploy por ambiente.

bundle:
  name: sales-data-pipeline

targets:
  dev:
    workspace:
      host: ${DATABRICKS_HOST}
    variables:
      environment: dev

  staging:
    workspace:
      host: ${DATABRICKS_HOST}
    variables:
      environment: staging

  prod:
    workspace:
      host: ${DATABRICKS_HOST}
    variables:
      environment: prod

resources:
  jobs:
    sales_pipeline_job:
      name: sales-pipeline-${var.environment}
      tasks:
        - task_key: bronze_ingestion
          notebook_task:
            notebook_path: ./notebooks/bronze/01_ingestion.py

        - task_key: silver_transform
          depends_on:
            - task_key: bronze_ingestion
          notebook_task:
            notebook_path: ./notebooks/silver/02_transform.py

        - task_key: gold_publish
          depends_on:
            - task_key: silver_transform
          notebook_task:
            notebook_path: ./notebooks/gold/03_publish.py

databricks bundle validate -t dev
databricks bundle deploy -t staging
databricks bundle run sales_pipeline_job -t staging
databricks bundle deploy -t prod

Exemplo 4: CI/CD com Snowflake

No Snowflake, scripts SQL, migrations, procedures e tasks podem fazer parte do fluxo de CI/CD, com validação antes do deploy.

sql/
├── migrations/
│   ├── V001__create_customer_table.sql
│   ├── V002__add_customer_status_column.sql
│   └── V003__create_sales_fact_table.sql
│
├── procedures/
│   └── load_gold_sales.sql
│
├── tasks/
│   └── refresh_gold_sales_task.sql
│
└── views/
    └── vw_sales_summary.sql

-- V002__add_customer_status_column.sql
ALTER TABLE SILVER.CUSTOMERS
ADD COLUMN CUSTOMER_STATUS VARCHAR;

-- procedures/load_gold_sales.sql
CREATE OR REPLACE PROCEDURE GOLD.LOAD_SALES()
RETURNS STRING
LANGUAGE SQL
AS
$$
BEGIN
  INSERT INTO GOLD.SALES_SUMMARY
  SELECT
    SALE_DATE,
    CUSTOMER_ID,
    SUM(SALE_AMOUNT) AS TOTAL_AMOUNT
  FROM SILVER.SALES
  GROUP BY SALE_DATE, CUSTOMER_ID;

  RETURN 'GOLD.SALES_SUMMARY updated successfully';
END;
$$;

-- tasks/refresh_gold_sales_task.sql
CREATE OR REPLACE TASK GOLD.REFRESH_SALES_SUMMARY_TASK
WAREHOUSE = COMPUTE_WH
SCHEDULE = 'USING CRON 0 6 * * * UTC'
AS
CALL GOLD.LOAD_SALES();

Boas práticas de CI/CD em engenharia de dados

• Nunca altere produção manualmente sem rastreabilidade.
• Versione notebooks, SQLs, modelos dbt e configurações.
• Crie testes para transformações críticas.
• Separe ambientes de desenvolvimento, staging e produção.
• Use variáveis e secrets para credenciais.
• Não salve senhas no código.
• Crie documentação do pipeline e das regras de negócio.
• Padronize nomenclatura de pastas, tabelas, branches e arquivos.
• Use Pull Requests para revisão e histórico.
• Automatize validações antes do deploy.
• Monitore pipelines em produção.
• Tenha plano de rollback.

Erros comuns em CI/CD para dados

• Achar que CI/CD é só para desenvolvedores de software.
• Criar pipelines sem testes.
• Misturar ambiente dev com produção.
• Versionar apenas parte do projeto.
• Deixar notebooks soltos sem padrão.
• Fazer deploy manual sem revisão.
• Não documentar regras de negócio.
• Não usar secrets.
• Não monitorar depois do deploy.

Relação com Databricks, Snowflake e dbt

Como começar na prática

Checklist final de CI/CD para engenharia de dados

Links internos e externos sugeridos