Empacotamento, entrega e aceitação operacional

Do arquivo de origem ao executável

O plugin Maven do Boot usa repackage sobre o JAR ou WAR produzido pela fase package. O resultado inclui o layout e as dependências necessários à forma de execução configurada. O objetivo não deve ser interpretado como substituto da fase que produz o arquivo de origem.

Com starter-parent, a execução de repackage já está preparada e a declaração do plugin participa nesse padrão. Sem o parent, configura a execução explicitamente. O arquivo original recebe normalmente o sufixo .original; o pipeline deve selecionar o produto certo, em vez de escolher qualquer ficheiro com a mesma versão.

Ler o layout e o manifest

Num JAR reempacotado, classes da aplicação e bibliotecas ocupam normalmente BOOT-INF/classes e BOOT-INF/lib. O plugin Boot gere entradas do manifest como Main-Class e Start-Class. Alterar apenas uma extensão ou uma entrada no jar plugin não reproduz todo esse contrato.

Quando um candidato não arranca, compara primeiro o tipo de artefacto selecionado, o layout e a classe principal com o modelo de empacotamento. Aumentar memória não converte um .original no executável esperado. O diagnóstico deve conservar a identidade exata dos bytes que produziram a falha.

Identidade declarada e conteúdo

build-info gera META-INF/build-info.properties com coordenadas e informação do build, que o Actuator pode apresentar. Essa metadata ajuda a responder que versão a instância declara. Não é uma assinatura criptográfica, uma prova de integridade ou uma aprovação de produção.

Dois builds podem declarar a mesma versão e ter conteúdo diferente. Se a política exige promover exatamente o candidato revisto, conserva um identificador de conteúdo e a sua ligação à evidência de aceitação. Copiar a metadata de um candidato aprovado para outro não transfere a validade dessa revisão.

Camadas segundo a frequência de mudança

O índice de camadas distingue dependências estáveis, loader, dependências snapshot e aplicação. A separação permite que ferramentas reutilizem camadas que não mudaram quando apenas o código da aplicação é atualizado. O benefício depende de o processo de construção usar essa organização.

Uma imagem em camadas continua a precisar de dependências compatíveis, identidade controlada e configuração adequada. Reutilizar uma camada não demonstra que as bibliotecas estão atualizadas nem que o serviço está pronto para receber tráfego. O índice organiza conteúdo; não substitui a decisão de aceitação.

Reconciliar os prazos de paragem

A paragem graciosa ocorre durante o fecho do contexto e dá aos pedidos existentes um período limitado, deixando de aceitar novos pedidos segundo o comportamento do servidor. spring.lifecycle.timeout-per-shutdown-phase configura o prazo por fase. Não prolonga automaticamente o prazo imposto por um supervisor externo.

Se a aplicação pede 20 segundos e a plataforma termina o processo aos 10, um pedido de 15 segundos pode perder a resposta. A retirada de tráfego, as fases de paragem e a terminação externa precisam de um orçamento coerente. Um sinal de terminação abrupta pode impedir o percurso gracioso.

Resultado incerto depois de uma interrupção

Perder uma resposta não prova que a operação não teve efeitos. Uma escrita pode confirmar antes de a ligação ser interrompida. A decisão de repetição precisa de uma identidade de operação, de observação do resultado e de uma política que evite duplicação quando essa propriedade é exigida pelo negócio.

Graceful shutdown reduz interrupções dentro das suas condições, mas não oferece rollback universal nem conclusão ilimitada. No cenário desta aula, o próximo passo é reconciliar o efeito persistido e os prazos reais. Reiniciar o processo não apaga automaticamente reservas, mensagens ou ações remotas já confirmadas.

Aceitar e recuperar com dependências reais

Uma decisão de promoção deve ligar o conteúdo candidato a verificações de comportamento e a uma recuperação viável. health UP e a versão esperada são sinais úteis, mas não cobrem automaticamente autorização, contratos HTTP, dados, operações demoradas ou consumidores externos. Escreve os limites de cada evidência.

Se uma migração remove uma coluna exigida pela versão anterior, voltar ao JAR antigo pode falhar. A recuperação precisa de considerar o estado dos dados e as versões que com ele coexistem. No exercício, escolhe decisões fundamentadas nos registos fornecidos; não é pedida execução de builds, containers ou migrações.

Armadilhas comuns

Publicar .original por engano; tratar build-info como assinatura; presumir que camadas garantem segurança; configurar um prazo de paragem superior ao da plataforma; voltar ao binário antigo sem verificar compatibilidade dos dados.