Quebrar o build: o que é, causas e como evitar no projeto

O que é quebrar o build no desenvolvimento

Quebrar o build é uma situação onde, após introduzir alterações, o projeto para de compilar. No contexto de CI/CD, isso significa que o pipeline de build falha e nenhum artefato é criado.

No mundo do desenvolvimento móvel e web, o build é o processo de traduzir o código fonte em um arquivo executável ou pacote. Para Android, é a criação de um APK ou AAB via Gradle; para iOS, a compilação via Xcode; para projetos web, o empacotamento via Webpack ou Vite. Você pode quebrar o build em qualquer uma destas etapas.

Sistemas modernos de controle de versão e ferramentas CI/CD como Jenkins, GitHub Actions e GitLab CI detectam automaticamente um build quebrado e notificam a equipe. Na maioria dos projetos existe uma regra: se o build está quebrado, a prioridade de todas as outras tarefas é reduzida até que o build seja corrigido.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Esta linha quebra o build
    val number: Int = "not a number"
}

Neste exemplo, atribuir uma string a uma variável do tipo Int causa um erro de compilação. A incompatibilidade de tipos é uma das causas mais comuns de build quebrado em linguagens estaticamente tipadas.

Principais causas de falha no build

Existem várias categorias de erros que levam a um build quebrado. De acordo com a análise do GitLab para 2024, a distribuição das causas é a seguinte.

A categoria mais insidiosa são os problemas de dependência. Atualizar uma biblioteca em um módulo pode quebrar o build em um módulo vizinho se a API ou o comportamento dos métodos mudar.

Erros de sintaxe, por outro lado, são detectados rapidamente — o compilador aponta a linha exata e o tipo do erro. É por isso que linguagens estaticamente tipadas são consideradas mais confiáveis em termos de estabilidade de build do que as dinamicamente tipadas.

Como um build quebrado afeta a equipe

Um build quebrado afeta diretamente a produtividade da equipe. Quando o build falha, os desenvolvedores não podem obter a versão mais recente do projeto do repositório, e o pipeline de CI fica bloqueado para todas as alterações subsequentes.

Um estudo da Atlassian de 2023 mostrou que projetos onde o build permanece quebrado por mais de quatro horas perdem em média 25% do tempo produtivo da equipe. Os desenvolvedores são forçados a desviar sua atenção para diagnosticar o problema em vez de concluir suas tarefas.

Além da produtividade, o clima moral também é afetado. O desenvolvedor que quebrou o build sofre pressão dos colegas. Em equipes saudáveis, a regra é: não punir por um build quebrado, mas exigir correção imediata. A cultura sem culpa é uma abordagem onde o incidente é analisado como um problema sistêmico, não como um erro de alguém.

Em equipes distribuídas, um build quebrado pode bloquear o trabalho de colegas em outro fuso horário. Se um desenvolvedor da Europa quebra o build antes de sair, a equipe da Ásia pode perder um dia inteiro de trabalho esperando a correção.

Como prevenir um build quebrado

A prevenção do build quebrado começa com verificações locais antes do commit. Cada desenvolvedor deve executar testes e o build antes de enviar alterações. Os principais métodos de prevenção são divididos em vários níveis.

• Hooks pre-commit — verificações automáticas antes de criar um commit, incluindo linters e formatadores
• Build local — executar a compilação antes do push, especialmente em linguagens estaticamente tipadas
• Testes unitários — cobertura dos módulos principais com testes para detecção precoce de regressões
• Revisão de código — revisão das alterações por um colega antes de mesclar na ramificação principal

O segundo nível é a configuração do pipeline CI/CD. Cada Pull Request deve passar pelo build e testes automáticos antes da mesclagem. Se o build falhar, o PR é bloqueado até ser corrigido. Esta abordagem é chamada de gated commit e é usada na maioria dos projetos modernos.

O terceiro nível é monitoramento e estatísticas. As equipes acompanham a métrica MTTR (Mean Time To Repair). Quanto menor este indicador, mais rápida a equipe responde a um build quebrado. O valor alvo não ultrapassa 30 minutos.

O que fazer se o build estiver quebrado

Quando o build está quebrado, o primeiro passo é identificar qual desenvolvedor fez as últimas alterações. O Git fornece a ferramenta git bisect, que permite encontrar o commit que quebrou o build através de busca binária.

# Iniciar bisect com commits bom e ruim conhecidos
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git verifica um commit no meio
# Compile e teste, depois marque:
git bisect good  # if build passes
git bisect bad   # if build fails

# Após ~log2(n) passos, git mostra o culpado
git bisect reset

Após encontrar o commit problemático, existem dois possíveis cursos de ação. O primeiro é reverter as alterações usando git revert se a correção exigir tempo. Esta é a abordagem mais segura, especialmente quando o build bloqueia toda a equipe.

A segunda opção é uma correção imediata com um novo commit. Esta abordagem é preferível se o problema for local e claro. Após a correção, envie as alterações e confirme que o build passou. Em qualquer caso, o tempo de recuperação do build não deve exceder uma hora.