APRENDER. PRATICAR. EVOLUIR.O que está realmente a ser promovido
Começa por identificar a unidade da decisão. Numa release fictícia, a API 41 funciona com a configuração 7 e o batch 12. Um ticket que apenas diz API pronta deixa duas dependências por identificar. Constrói um registo com alvo, artefacto, configuração, dependências relevantes, evidência de validação e responsável. Depois compara esse registo com o que o job vai executar. Se a configuração mudou para 8, a identidade do binário pode continuar correta e a evidência de comportamento deixar de cobrir o conjunto. Em APS, este detalhe determina se uma equipa recebe um serviço previsível ou uma combinação nunca exercitada. O objetivo do registo é permitir a decisão e a investigação posteriores, com diferenças visíveis.
Uma tag não fixa os bytes
Executa o primeiro grupo do laboratório. O dicionário local associa candidate aos bytes A; guardamos o digest esperado e depois associamos a mesma tag aos bytes B. A comparação rejeita a substituição, enquanto os bytes A conservados continuam a corresponder. É um modelo de referência mutável, sem registry real. Faz uma previsão antes de correr o código: mudar o nome é necessário para mudar o conteúdo? Não. O digest permite comparar identidade, mas depende de uma referência fiável e não demonstra quem aprovou ou produziu o pacote. Para usar a ideia no trabalho, liga o artefacto identificado às evidências pertinentes e protege o caminho dessa referência até à promoção.
Executar um de cada vez não define a ordem
O segundo grupo começa em 40 e executa duas escritas sequenciais: 42 e depois 41. O resultado incondicional é 41, apesar de nunca existirem dois executores simultâneos. A versão seguinte aplica a condição seq menor que a intenção recebida. A escrita 42 altera uma linha; a escrita 41 altera zero; o alvo mantém 42. O resultado zero precisa de tratamento explícito, pois a instrução SQL pode terminar sem erro e não promover nada. Este é um modelo local de decisão monotónica, não uma prova de segurança de um controlador distribuído. Em GitLab, resource_group e o modo de processamento têm responsabilidades distintas; verifica também a política contra deployments desatualizados.
Recuperar pode ser uma nova decisão
Uma regra de atualidade não deve obrigar a escolher sempre bytes com um número de versão superior. No terceiro grupo, a intenção 43 aponta para artifact-40. O contador aumenta porque existe uma nova decisão, mesmo que o conteúdo selecionado seja anterior. Discute o que falta antes de transportar esta ideia para produção: autoridade, compatibilidade do estado, efeitos já produzidos, validação e procedimento de execução. O laboratório só demonstra a alteração condicionada do registo. Não demonstra recuperação de uma aplicação. Evita renumerar silenciosamente um job antigo para contornar a regra; a nova intenção tem de representar uma decisão real e rastreável sobre o estado observado.
Autorizações têm um âmbito
O sexto grupo compara uma aprovação de staging, configuração 7, com um pedido de produção, configuração 8. O digest é igual, mas ambiente e configuração diferem. O resultado enumera esses campos, sem consultar qualquer serviço de autorização. Usa a comparação para preparar perguntas concretas: quem pode decidir neste alvo, que evidência foi analisada e que alterações exigem nova avaliação? Em GitHub Actions, as regras do environment abrangem jobs que o referenciam; o nome visível production não substitui essa ligação. As funcionalidades disponíveis dependem do contexto e plano. Não concluas que uma aprovação foi aplicada a partir de um comentário isolado no ticket ou de um teste local de campos.
Oficina: rever a decisão de promoção
Prepara três cartões fictícios: estado atual 42, job pendente 41 e pedido de recuperação 43 para artefacto 40. Para cada cartão, escreve o efeito esperado, a evidência de identidade, o âmbito de autorização e a condição de paragem. Executa o laboratório e compara previsões com os registos. Depois altera apenas o alvo de staging para produção e explica porque o mesmo digest não conserva automaticamente a autorização. O resultado esperado da oficina é uma decisão justificada, incluindo o que ainda não foi demonstrado. Não existe pipeline real neste exercício. Resume a aprendizagem distinguindo conteúdo, intenção e permissão; relaciona-a com gestão de alterações, CI/CD e responsabilidade do suporte após a release.
python3 content/labs/release-evidence/run.py
# Sequential intents: 42, then 41
# Unconditional final sequence: 41
# Conditional update final sequence: 42; affected rows: [1, 0]
# New recovery intent: sequence 43, artifact-40
# Local SQLite model, not a vendor pipeline. Numa equipa fictícia de fundos, dois jobs aprovados em momentos diferentes chegam ao mesmo ambiente fora da ordem pretendida.
Armadilhas comuns
Confiar numa tag mutável, equiparar hash a autorização, confundir lock com ordem e reutilizar uma aprovação fora do seu âmbito.
Tópicos relacionados: Gestão de alterações · CI/CD · Suporte à produção L3
Uma promoção precisa de conteúdo identificado, decisão atual e controlos que abranjam o caminho real de execução.
Referência: Release engineering · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation