Dagger: o motor de automação que transforma pipelines de CI/CD em código

O que é Dagger

Dagger e um motor de automação para construir, testar e publicar qualquer projeto de software, seja localmente, em um servidor de CI ou direto na nuvem. A proposta central e simples: em vez de escrever pipelines presos a sintaxe de um provedor específico de CI/CD, você escreve funções em uma linguagem de programação de verdade.

O projeto nasceu da equipe que criou o Docker, sob a liderança de Solomon Hykes, e vem crescendo de forma consistente no GitHub Trending, sinal de que resolve uma dor real de quem sofre para manter arquivos YAML gigantes de pipelines.

A ideia por trás do Dagger e tratar a automação de build e deploy como qualquer outro módulo de software: com tipos, testes, versionamento e reuso entre projetos diferentes, algo que arquivos de configuração tradicionais nunca conseguiram entregar direito.

Como funciona

O Dagger roda um motor de execução em containers que processa suas funções de pipeline como um grafo de operações. Cada etapa (compilar, testar, empacotar, publicar) vira uma função que recebe entradas tipadas e devolve saídas tipadas, como se fosse uma API interna do seu pipeline.

Por baixo dos panos, ele usa o BuildKit (o mesmo motor de build do Docker moderno) para executar cada etapa dentro de containers isolados, com cache automático de camadas. Isso significa que uma etapa que não mudou desde a última execução não precisa rodar de novo.

Uma analogia útil: pense no Dagger como transformar seu pipeline de CI em um programa normal, que você pode rodar no seu notebook exatamente do mesmo jeito que roda no servidor de CI. Sem surpresas de "funciona na minha máquina, mas quebra no CI".

Principais recursos

• Pipelines como código real: escreva em Go, Python, TypeScript, PHP ou Java, com autocomplete, tipos e depuração normal da linguagem.
• Execução idêntica local e remota: o mesmo pipeline roda no seu notebook e no servidor de CI, sem reescrever nada.
• Cache automático de camadas: etapas que não mudaram são reaproveitadas, reduzindo bastante o tempo de build.
• Módulos reutilizáveis: e possível publicar e importar módulos de pipeline prontos, como pacotes de uma linguagem qualquer.
• Independência de provedor de CI: o pipeline não fica preso ao GitHub Actions, GitLab CI ou Jenkins, portar entre eles fica muito mais simples.
• Dagger Cloud: painel opcional com visualização detalhada de cada execução, útil para depurar falhas em pipelines longos.

Como começar: instalação ou acesso passo a passo

O Dagger e open source e pode ser instalado localmente em poucos minutos. Não existe custo para usar o motor principal, o que baixa bastante a barreira de entrada para times pequenos.

# instalar o Dagger CLI (Linux/macOS)
curl -fsSL https://dl.dagger.io/dagger/install.sh | sh

# verificar a instalação
dagger version

Depois de instalado, o passo seguinte e iniciar um módulo no seu projeto. O comando abaixo gera a estrutura básica na linguagem escolhida:

# iniciar um módulo Dagger em um projeto existente
dagger init --sdk=Python

# rodar uma função do pipeline
dagger call build --source=.

Para times que já tem pipelines em YAML, a migração costuma ser gradual: e possível começar convertendo só uma etapa (por exemplo, os testes) e ir expandindo aos poucos, sem precisar reescrever tudo de uma vez.

Exemplo prático

Imagine um time que mantem uma API em Python e sofre com um pipeline de CI que demora 12 minutos, mesmo quando só um arquivo de teste mudou. Com Dagger, a função de build fica assim, de forma simplificada:

import dagger
from dagger import dag, function, object_type

@object_type
class MinhaApi:
    @function
    async def test(self, source: dagger.Directory) -> str:
        return await (
            dag.container()
            .from_("Python:3.12-slim")
            .with_directory("/app", source)
            .with_workdir("/app")
            .with_exec(["pip", "install", "-r", "requirements.txt"])
            .with_exec(["pytest"])
            .stdout()
        )

Ao rodar essa função pela segunda vez sem alterar as dependências, o Dagger reaproveita a camada de instalação dos pacotes e executa só os testes de novo, cortando boa parte do tempo total da etapa.

Comparação com alternativas

O concorrente mais direto e continuar usando a sintaxe nativa de cada provedor, como GitHub Actions ou GitLab CI. Elas funcionam bem para pipelines simples, mas ficam difíceis de testar localmente e de reaproveitar entre projetos.

Ferramentas como Earthly tentam resolver um problema parecido, com uma sintaxe própria inspirada em Dockerfile. A diferença do Dagger e não inventar uma linguagem nova: você usa a linguagem de programação que o time já domina.

Já o Bazel resolve builds reproduzíveis para monorepos gigantes, mas tem uma curva de aprendizado bem mais alta. O Dagger tende a ser mais acessível para times médios que querem sair do YAML sem adotar um sistema de build inteiro.

Pontos positivos e limitações

Entre os pontos fortes estão a portabilidade real entre ambientes, o cache eficiente e a possibilidade de testar o pipeline inteiro localmente antes de dar push, o que evita aquele ciclo lento de commit, esperar o CI e corrigir.

Por outro lado, times acostumados com YAML podem levar um tempo para se adaptar a escrever pipelines como código, especialmente times sem muita familiaridade com containers.

Outra limitação real e que integrações muito específicas de um provedor de CI, como certas actions prontas do marketplace do GitHub, ainda exigem algum trabalho manual para replicar dentro de uma função Dagger.

Casos de uso reais

Times de plataforma que mantem pipelines para dezenas de repositórios usam o Dagger para criar módulos padronizados de build e teste, reaproveitados por todos os times sem duplicar configuração.

Startups em crescimento que trocam de provedor de CI (por exemplo, saindo do Jenkins para o GitHub Actions) usam o Dagger como camada de abstração, para não precisar reescrever o pipeline inteiro de novo a cada troca.

Desenvolvedores individuais em projetos open source usam o Dagger para rodar a mesma suite de testes localmente e no CI, eliminando o famoso problema de um teste passar na máquina do desenvolvedor e falhar só no servidor.

Times de dados e ML que precisam empacotar pipelines com dependências pesadas (bibliotecas de machine learning, drivers de GPU) usam o cache do Dagger para não reinstalar tudo a cada execução.

Dicas e boas práticas

Um erro comum de quem esta começando e tentar migrar o pipeline inteiro de uma vez. O caminho mais seguro e converter uma etapa isolada primeiro, validar o resultado, e só depois expandir para o restante do pipeline.

Vale a pena?

Para times que já sentem dor de manter pipelines YAML grandes, duplicados entre repositórios, ou que trocam de provedor de CI com alguma frequência, o Dagger vale muito o investimento de aprendizado inicial.

Para projetos pequenos com um pipeline simples de poucas etapas, a sintaxe nativa do provedor de CI ainda pode ser suficiente, sem necessidade de adicionar mais uma ferramenta ao stack.

Se o seu time se encaixa no primeiro grupo, o próximo passo natural e instalar o CLI localmente e converter uma única etapa do pipeline atual, só para sentir na prática o ganho de cache e portabilidade.