Build entrega e decisão final

Identificar exatamente o que será disponibilizado

Build é a preparação de um artefato utilizável a partir dos arquivos do projeto. Mesmo quando uma aplicação JavaScript dispensa compilação, é preciso identificar o conjunto que será executado. Entrega, neste capítulo, é a disponibilização desse conjunto ao ambiente ou à pessoa responsável. Implantação o coloca em execução no destino. Homologação é a avaliação do resultado pelos critérios de aceite. Declarar essas convenções evita confundir código mais recente com versão efetivamente avaliada.

Na Oficina Caracol, a entrega reúne código, dados artificiais, configuração documentada e instruções de operação. O commit identifica uma revisão do repositório; a versão identifica uma entrega segundo a política adotada. Um artefato anterior guardado é útil, mas a reversibilidade depende de conseguir usá-lo com os dados e a configuração disponíveis. Esse vínculo precisa ser ensaiado antes que uma recuperação seja necessária.

Ficha preenchida para preparação

Procedimento de preparação e liberação

• Parta de uma revisão identificada e confira o runtime com node --version. Registre o valor observado; não copie o número de outro ambiente como se fosse sua execução.
• Execute npm test e npm run validate dentro de pratica. Preserve a saída pertinente e investigue falhas, inclusive diferenças de ambiente e configuração.
• Inicie com npm start e realize as verificações manuais aplicáveis no endereço local documentado. Relacione cada resultado ao requisito correspondente.
• Execute npm run snapshot para preparar o ensaio de dados artificiais em sandbox/recuperacao, conforme o contrato do pacote. Confirme a existência e identificação do snapshot antes de prosseguir.
• Execute o ensaio de npm run restore somente em sandbox/recuperacao. Compare o arquivo restaurado com a referência documentada. O catálogo fonte não é sobrescrito. As verificações dos fluxos da aplicação são realizadas separadamente sobre o catálogo que o servidor efetivamente usa; esse ensaio não constitui recuperação de produção.
• Reúna resultados aceitáveis, exceções não impeditivas aceitas e condições de retorno. Autorize a liberação apenas depois dessa avaliação.

Demonstrar o retorno em vez de presumir

O cenário de ensaio usa apenas sandbox/recuperacao. O conjunto de referência contém A ativo e B inativo; após preparar o snapshot, uma alteração didática no arquivo de trabalho dessa área controlada introduz uma entrada inválida. O roteiro de restauração deve recuperar o conteúdo de referência. Conferem-se identificadores e campos relevantes, além da igualdade esperada com a cópia identificada. São critérios do ensaio, não resultados já observados. O catálogo fonte e o servidor em execução não são alterados pelo restore.

A ficha do ensaio liga snapshot, versão de código, configuração, passos e observações. Recuperar arquivos demonstra uma parte da capacidade; operar a aplicação com dados recuperados exige ainda verificar compatibilidade e comportamento no destino escolhido. Em um sistema real, essa etapa faria parte de um roteiro específico e ensaiado. Uma mudança irreversível pode exigir correção adiante ou migração própria. A decisão de disponibilizar considera esses limites de forma explícita.

Erros e reparos

Condição de avanço

O gate final exige artefato identificável, resultados aplicáveis aprovados, integração comprovada, aceite pertinente e recuperação compatível com o risco. Uma exceção só pode permanecer quando é não impeditiva e foi aceita por autoridade responsável. Quando a entrega muda depois da avaliação, as evidências afetadas precisam ser renovadas; o simples decurso do tempo não determina sozinho sua validade.

Exercício com solução

Dados da candidata: testes automatizados aprovados; validação aprovada; foco invisível em um controle obrigatório; snapshot presente; restauração nunca ensaiada. A equipe quer anunciar a versão hoje. Decida o gate e preencha duas ações prioritárias.