> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Builds diferenciais
> Acelere os builds do snapshot reconstruindo apenas os workspaces cujos blueprints foram alterados. Os workspaces que não sofreram alterações são herdados do build bem-sucedido anterior.
## Visão geral
Por padrão, todo build do snapshot é um **build completo** — ele parte de uma imagem base limpa, clona todos os repositórios e executa cada blueprint do zero. Isso garante um ambiente totalmente reproduzível, mas pode ser demorado quando você alterou apenas um blueprint entre vários.
**Builds diferenciais** otimizam esse processo reutilizando o snapshot do build bem-sucedido anterior como ponto de partida. Apenas os workspaces cujos blueprints realmente foram alterados são reconstruídos; os workspaces inalterados são herdados do build pai como estão. Isso pode reduzir significativamente o tempo de build, especialmente para organizações com muitos repositórios.
## Ativando builds diferenciais
Vá para **Configurações > Ambiente > Avançado**.
Ative o controle **build diferencial**. A descrição diz: *"Builds mais rápidos ao reutilizar workspaces inalterados."*
Salve uma alteração no blueprint ou clique em **Build snapshot**. O próximo build tentará ser executado como um build diferencial se houver um build pai válido.
O primeiro build após ativar builds diferenciais sempre será um **build completo** — o sistema precisa de um snapshot de base bem-sucedido para fazer a comparação. Os builds subsequentes serão diferenciais desde que exista um build pai válido.
## Como funciona
Quando um build é acionado com builds diferenciais ativados, o sistema segue este processo:
### 1. Encontrar uma build pai
O sistema procura a build bem-sucedida mais recente (status `success` ou `partial`) para usar como build pai. Se não houver uma build pai válida, a build recorre automaticamente a uma build completa.
### 2. Comparar blueprints
A configuração de cada workspace é comparada à build pai. O sistema calcula um digest das entradas de cada workspace — incluindo o conteúdo do blueprint, arquivos anexados, segredos e a ordem dos repositórios — e verifica o que mudou.
### 3. Atribuir ações aos workspaces
Com base na comparação, cada workspace recebe uma de três ações:
| Ação | O que acontece | Quando é usada |
| --------------- | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| **Reconstruir** | Clonar o repo e executar todas as etapas do blueprint (initialize + maintenance) do zero | O blueprint mudou desde o build pai |
| **Herdar** | Baixar o código mais recente e executar apenas as etapas de `maintenance` | O blueprint não foi alterado — reutilize a configuração do pai |
| **Remover** | Excluir o workspace do snapshot | O workspace foi removido da configuração |
Para workspaces herdados, `initialize` não é executado novamente. Escreva `maintenance`
de modo que seja autossuficiente e possa ser executado de forma independente depois que o código mais recente
for baixado. Ele pode usar tools e runtimes já instalados no snapshot pai,
mas não deve exigir que `initialize` seja executado imediatamente antes nem depender de
variáveis de ambiente que `initialize` tenha gravado anteriormente em `$ENVRC`.
### 4. Execute o build
O build começa a partir da imagem de snapshot do build pai, em vez de uma base limpa. Isso significa:
* **Workspaces herdados** já têm suas ferramentas, runtimes e dependências instalados. O sistema atualiza o código para a versão mais recente (`git pull`) e executa os comandos de `maintenance` para atualizar as dependências.
* **Workspaces reconstruídos** são configurados do zero — clonados novamente e passam pela sequência completa de `initialize` + `maintenance`.
* **Workspaces removidos** têm seus diretórios limpos.
Blueprints de organização e Enterprise pulam `initialize` durante build diferencial (já que essas ferramentas já estão presentes na imagem pai) e executam apenas `maintenance`.
`$ENVRC` é redefinido no início de todo build, incluindo build diferencial.
Variáveis de ambiente e entradas de `PATH` gravadas em `$ENVRC` por um build
anterior não são herdadas. Se `maintenance` precisar delas, deverá configurá-las
por conta própria.
## Quando o sistema executa um build completo
Mesmo com os builds diferenciais ativados, o sistema faz fallback para um build completo em determinadas situações:
* **Não existe build pai** — é o primeiro build ou todos os builds anteriores falharam
* **O blueprint da organização ou Enterprise mudou** — mudanças globais afetam todos os workspaces, então um rebuild limpo é mais seguro
* **A ordem dos repositórios mudou** — como os repos podem depender da configuração uns dos outros, mudar a ordem aciona um rebuild completo
* **O build pai é antigo demais ou incompatível** — o sistema valida se o build pai é adequado
Quando ocorre um fallback, a página de detalhes do build mostra o motivo no badge do tipo de build.
## Como visualizar o tipo de build
Depois que uma build é concluída, você pode ver se ela foi executada como diferencial ou completa:
1. Vá para **Configurações > Ambiente > Snapshots**
2. Clique em uma build no histórico
3. O selo **Tipo de build** mostra **Diferencial** (azul) ou **build completo** (padrão)
Passe o cursor sobre o selo para ver uma dica explicando o que cada tipo significa:
* **Diferencial**: *"Somente os workspaces alterados são reconstruídos; os que não foram alterados são herdados da última build bem-sucedida com a mesma configuração"*
* **build completo**: *"Todos os workspaces são criados do zero"*
## Benefícios
| Benefício | Descrição |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Builds mais rápidos** | Apenas os workspaces alterados passam pelo processo completo de configuração. Os workspaces herdados pulam `initialize` completamente. |
| **Menor uso de rede** | Os workspaces inalterados não baixam novamente ferramentas, runtimes nem dependências grandes. |
| **Iteração mais rápida** | Ao iterar no blueprint de um único repositório, os outros repositórios não deixam o build mais lento. |
| **Mesma confiabilidade** | Se algo parecer errado, o sistema recorre automaticamente a um build completo. Você também pode acionar manualmente um build completo a qualquer momento. |
## Acionando manualmente um build completo
Mesmo com build diferencial ativado, você pode forçar um build completo pelo botão **Build snapshot**. Use o menu suspenso para selecionar **build completo** em vez da opção diferencial padrão.
Recomendamos executar um build completo periodicamente para descartar o estado herdado e verificar se seus blueprints ainda conseguem criar o ambiente do zero. Execute também um após remover ou substituir uma configuração que possa ter deixado arquivos, ferramentas ou dependências obsoletos no snapshot. Um build completo executa novamente todas as etapas `initialize` e `maintenance`.
## Perguntas frequentes
Não. As sessões sempre são iniciadas a partir do snapshot final, independentemente de como ele foi gerado. A única diferença é a velocidade do build.
Fixe uma build anterior comprovadamente estável em **Configurações > Ambiente > Snapshots** e, em seguida, acione uma build completa para obter um snapshot limpo. Você também pode desativar totalmente os builds diferenciais para voltar às builds completas.
Sim. Uma build com status `partial` (alguns workspaces foram concluídos com sucesso, outros falharam) pode servir como pai. O sistema herda apenas dos workspaces que foram bem-sucedidos na build pai.