Skip to main content

​
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

1

Navegue até as configurações do ambiente

Vá para Configurações > Ambiente > Avançado.
2

Ative o controle

Ative o controle build diferencial. A descrição diz: “Builds mais rápidos ao reutilizar workspaces inalterados.”
3

Acione um build

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.
Ativar builds diferenciais não força um build completo. Se já existir um build anterior bem-sucedido ou parcial para a mesma plataforma e configuração da máquina, o próximo build pode usá-lo como build pai e herdar seu estado. O próximo build só é executado como build completo nas situações listadas em Quando um build completo é executado no lugar. Para começar de uma base limpa, selecione build completo no dropdown Build snapshot.

​
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) com uma imagem do snapshot para a mesma plataforma e configuração da máquina 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 e segredos — 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:
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 um build completo é executado em vez disso

Mesmo com builds diferenciais ativados, o build é executado como build completo nestas situações:
  • Você solicita um build completo — você seleciona build completo no menu suspenso Build snapshot
  • O build completo mais recente está muito antigo — um build automático, como o acionado ao salvar um blueprint, é executado como build completo quando não existe nenhum build completo para a plataforma dele ou quando o mais recente é mais antigo que o intervalo build completo refresh em Configurações > Ambiente > Avançado (a cada 7 dias, por padrão)
  • Não existe build pai reutilizável — não há build success ou partial com imagem do snapshot para a mesma plataforma e configuração da máquina
  • O build pai é incompatível — a plataforma, a configuração da máquina, a imagem base ou a configuração Clone repositories on all platforms mudou desde o build pai, ou o build pai não tem uma base de segredos para comparação
  • A configuração da organização ou do enterprise mudou — um blueprint de organização ou enterprise, um arquivo de blueprint ou um segredo mudou desde o build pai
Mudanças com escopo em repositórios individuais mantêm o build diferencial. Novos repositórios, mudanças de blueprint ou de segredos de um repositório e repositórios que falharam no build pai são reconstruídos dentro do build diferencial. Reordenar repositórios não aciona um build completo. Quando um build solicitado como diferencial acaba sendo executado como build completo, a dica de contexto tipo de build na página de detalhes do build mostra o motivo.

​
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

​
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.