Conceito e mecanismo
Uma release liga alterações técnicas a um resultado disponibilizado ao utilizador. O deployment instala ou altera componentes; a disponibilização de uma funcionalidade pode ocorrer depois, por configuração ou feature flag. Essa separação permite controlar exposição, mas não retira risco às alterações de configuração. Define o âmbito com serviços, componentes, versões, dependências e critérios de aceitação. Uma lista de tickets concluídos não explica por si só se o conjunto é compatível ou utilizável. Identifica responsáveis por decisões, execução, validação funcional e suporte. A coordenação pode abranger várias equipas e países, sem exigir que a pessoa que gere a release execute todos os comandos.
Aplicação guiada
Num exemplo fictício, uma atualização de API depende de middleware, schema e um batch de reconciliação. Regista sequência e combinações de versões suportadas, incluindo o período de coexistência. Se surgir um pedido tardio, avalia impacto no pacote já testado, no prazo e na recuperação antes de o incluir. Planeia janelas com fuso horário, duração estimada, critérios para não avançar e cobertura fora de horas. Um calendário reservado não demonstra prontidão. Comunica limitações conhecidas e impacto esperado ao negócio com linguagem compreensível. Os exemplos deste percurso não representam o calendário nem os comités de qualquer banco. Usa a governação aplicável ao contexto, sem presumir uma reunião CAB para cada deployment automatizado.
Uma API instalada pode continuar desativada até a reconciliação e o suporte estarem preparados.
Armadilhas comuns
Deployment como aceitação; pedido tardio sem reavaliar; calendário como prontidão.
Tópicos relacionados: Artefactos e rastreabilidade · Prontidão e autorização · Exposição e observação
Liga âmbito, dependências e decisões ao resultado que o serviço deve entregar.
Referência: Release contents operational coordination and API compatibility · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation