Conceito e mecanismo
Uma decisão de go/no-go combina evidência técnica, capacidade operacional e risco aceite. Define previamente critérios proporcionais ao serviço: testes relevantes, compatibilidade, monitorização, recuperação, dependências e pessoas disponíveis. Se um requisito essencial não foi cumprido, a proximidade do prazo não o transforma em aprovado. Torna o desvio explícito e encaminha a decisão para a autoridade adequada. Checklists devem refletir riscos reais e aprender com incidentes anteriores; copiar uma lista extensa sem compreender o contexto pode esconder as perguntas importantes. Confirma também quem executa validação do negócio e quem pode interromper a operação. A prontidão precisa de existir antes de a equipa se dispersar no fim de semana.
Aplicação guiada
Os controlos da plataforma só funcionam dentro do âmbito configurado. Em GitHub Actions, as regras de um environment aplicam-se aos jobs que o referenciam. Uma lista de required reviewers não exige por defeito aprovação de todos; impedir autoaprovação é uma opção específica. Em GitLab, a janela de freeze fornece CI_DEPLOY_FREEZE e as regras dos jobs precisam de usar esse sinal para impor o bloqueio descrito. Um calendário sem enforcement não demonstra proteção. As funcionalidades variam com plano e configuração. Para emergência, usa o processo acelerado acordado, com decisor, critérios e evidência; regista verificações adiadas e acompanha-as. Urgência não equivale a uma dispensa silenciosa de toda a validação.
Uma regra de aprovação num environment não protege um job que o ignora.
Armadilhas comuns
Aprovação como saúde; freeze só no calendário; emergência como bypass sem registo.
Tópicos relacionados: Âmbito e coordenação · Artefactos e rastreabilidade · Exposição e observação
Decide com evidência e confirma que os controlos abrangem o caminho real de execução.
Referência: Launch coordination dependencies capacity and operational processes · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation