Entregar uma versão que o próximo ambiente consegue executar

Receber o código e uma imagem de aplicação não prova que o próximo responsável consegue pôr o trabalho a funcionar no ambiente combinado. O artefacto pode estar completo e, ainda assim, ter sido preparado para uma arquitetura diferente. A entrega deve verificar a compatibilidade e uma tarefa útil, não apenas a existência de um ficheiro.

Este cenário fictício acompanha um pequeno serviço que prepara listas internas de materiais. Não descreve uma alteração de infraestrutura real nem um teste executado num servidor de cliente. Os identificadores distinguem origem, versão e artefactos dentro da demonstração.

Identificar o destino antes de tentar executar

A versão R-12 foi preparada a partir da origem S-12 para linux/amd64. O destino acordado para o próximo responsável é linux/arm64, sem um mecanismo de emulação autorizado no cenário. A primeira tentativa registada falha antes de processar qualquer lista, com uma recusa de formato executável.

A investigação seguinte inspeciona o destino e o manifesto do artefacto antes de repetir a execução. O manifesto confirma que a imagem A-12 contém apenas a variante amd64. O identificador da versão e a integridade do ficheiro estão corretos; o problema não é uma descarga incompleta ou uma configuração comercial diferente.

A documentação de imagens multiplataforma do Docker explica a relação entre arquitetura do anfitrião, conteúdo executável e variantes de uma imagem. A existência de um contentor não torna qualquer binário compatível com todos os processadores. As opções de construção e execução precisam de corresponder ao ambiente efetivo.

Obter a variante suportada da mesma origem

A equipa responsável pela construção prepara B-12 para o destino arm64, usando a mesma origem S-12 e as dependências aprovadas para essa versão. Não aproveita a correção para introduzir uma funcionalidade nova ou atualizar silenciosamente regras de negócio.

O manifesto de B-12 identifica a plataforma esperada, e o resumo criptográfico permite conferir que o artefacto recebido é aquele que foi entregue. Esse controlo de integridade não demonstra, sozinho, que a aplicação funciona. A passagem precisa de uma execução autorizada num ambiente isolado correspondente ao destino.

A-12 continua disponível para o seu ambiente amd64. Não se substitui a etiqueta de arquitetura de um binário para o fazer parecer adequado. Também não se assume que a emulação resolverá todas as dependências, o desempenho ou o suporte do sistema.

Concluir uma tarefa reconhecível

A amostra de aceitação contém três linhas fictícias, M-1, M-2 e M-3, com quantidades 2, 4 e 1. O resultado esperado é uma lista com as mesmas referências e quantidades, mais o total de sete unidades. A aplicação não envia mensagens nem atua sobre sistemas externos durante esta demonstração.

No registo fictício concluído, B-12 inicia no destino arm64 isolado e produz as três linhas e o total sete. O próximo responsável abre a saída, compara as referências e confirma que nenhuma linha foi omitida. A verificação observa a tarefa para que a ferramenta existe, não apenas um processo que permaneceu em execução.

A-12 executa a mesma amostra no seu destino amd64 de controlo e produz o mesmo resultado de negócio. Os artefactos têm conteúdos binários próprios, mas preservam a origem funcional e a saída aprovada. Uma entrada incompleta continua a produzir a recusa definida para o serviço, sem uma lista parcial apresentada como concluída.

Preservar o caso desconhecido

Um terceiro destino chega sem informação suficiente sobre a plataforma. A entrega para esse ambiente fica pendente de verificação; não se escolhe a imagem pelo nome comercial do equipamento. O registo identifica quem deve fornecer a informação e qual a condição necessária para continuar.

Estes resultados não demonstram compatibilidade com todos os sistemas operativos, processadores ou serviços geridos. Também não estabelecem capacidade para carga real. A aceitação pertence à versão, ao ambiente e à tarefa descritos; outras condições precisam do seu próprio âmbito de verificação.

O que deve ficar com o sucessor

A documentação identifica a origem S-12, os artefactos A-12 e B-12, os destinos suportados, o modo autorizado de obter futuras construções e a amostra de aceitação. Regista também os acessos, a pessoa responsável pela construção e o procedimento quando surge um destino desconhecido.

A responsabilidade não termina num ficheiro comprimido. O próximo mantenedor precisa de saber qual a versão correta, por que motivo foi escolhida e como repetir a tarefa de controlo sem dados de clientes. As condições de manutenção e atualização permanecem parte do acordo de apoio.

O serviço de manutenção pode incluir esta preparação quando for contratada. Ao discutir a entrega, indique quem ficará com a aplicação e onde ela terá de funcionar. Essa informação deve entrar no planeamento antes de o projeto depender de um artefacto que só funciona no ambiente de quem o construiu.