APRENDER. PRATICAR. EVOLUIR.O arquivo também contém decisões de construção
O laboratório escreve dois ficheiros originais num ZIP: app.py e dependency.py. Cria representações com datas de 2026 e 2027, preservando os mesmos bytes dos membros. Os hashes por ficheiro coincidem, mas o SHA-256 do arquivo completo difere. Noutro grupo, inverte apenas a ordem de inclusão e volta a observar identidade global diferente. Isto é relevante quando QA aprova um pacote e o deployment o volta a gerar: conteúdo interno aparentemente igual não garante os mesmos bytes entregues. Define se o identificador da release representa o arquivo completo, os membros ou outro objeto. Não mudes implicitamente de critério para contornar uma rejeição; uma equivalência alternativa exige uma decisão explícita e rastreável.
Normalização com limites observáveis
O build normalizado ordena os nomes, fixa a data em 1980-01-01, explicita metadados Unix e usa ZIP_STORED. Duas construções no mesmo ambiente produzem bytes iguais. O exercício escolhe armazenamento sem compressão para reduzir variáveis; não afirma que esse seja o formato obrigatório de uma release real. A normalização deve fazer parte do processo revisto, porque alterar datas depois da aprovação também muda o digest. Conserva a toolchain, entradas e política de metadados. O resultado foi observado em CPython 3.13.1 sobre Darwin arm64, não numa matriz de sistemas ou versões de ferramentas. Reproduzir os mesmos bytes também pode reproduzir o mesmo defeito, pelo que a verificação funcional continua necessária.
A aplicação principal não fixa as dependências
app.py importa SCALE de dependency.py e multiplica-o por dez. A primeira dependência define dois e a segunda define três. O guião inicia dois processos Python com essas entradas originais e observa 20 e 30, mantendo os bytes de app.py. Não descarrega bibliotecas nem executa ficheiros extraídos dos ZIP. A experiência isola uma entrada do comportamento e mostra por que um rebuild da mesma aplicação pode não equivaler ao conjunto revisto. Num cenário APS, identifica dependências resolvidas, ferramentas, configuração e artefactos produzidos. Se o pacote aprovado se perder, reconstruir com dependências atuais cria uma candidata que precisa de avaliação; o prazo da janela não transforma essa candidata na versão já testada.
Recuperar um artefacto identificado
O plano de recuperação deve conservar acesso aos bytes necessários e à evidência que permite identificá-los. Um caminho chamado old.zip pode ter sido sobrescrito; uma etiqueta estável no relatório pode resolver conteúdo diferente mais tarde. Regista a relação entre versão, digest, entradas e resultado de validação, com conservação adequada ao serviço. Isso não garante que o pacote anterior seja compatível com o estado atual: migrações, configuração e efeitos já produzidos continuam a precisar de análise. No exercício fictício, se a divergência é descoberta perto do cut-off, decide nova entrega ou reagendamento com margem para validar. Trocar apenas o hash esperado pelo recebido elimina o controlo em vez de tratar a alteração.
python3 content/labs/release-artifacts/run.py --output /tmp/dr-release-artifacts.json
# Compare timestampChangesArchiveIdentity and sameApplicationDifferentInput.
# Only original local fixtures; no package download or archive execution.Os mesmos membros com datas diferentes mudam o digest do ZIP; o mesmo app.py com outra dependência muda o resultado de 20 para 30.
Armadilhas comuns
Fonte principal como build completo, hash por membro como identidade de todo o arquivo ou duas repetições locais como garantia universal.
Tópicos relacionados: Manifestos e proveniência · Promoção e recuperação
A identidade depende do âmbito escolhido e das entradas reais; controla metadados e dependências e conserva a evidência do artefacto entregue.
Referência: Archive metadata · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation