O que é a gestão de releases?
"O objetivo da prática de gestão de releases é disponibilizar versões novas e alteradas de serviços e componentes para uso, tanto em ambientes de teste como de produção."
A gestão de releases (release management) trata de agrupar, empacotar e disponibilizar alterações de forma organizada e controlada. Uma release reúne um conjunto de mudanças relacionadas - correções de erros, novas funcionalidades, atualizações de configuração - que são testadas e entregues em conjunto como uma unidade coerente.
Antes de chegar à produção, uma release percorre várias etapas: é construída, testada em múltiplos ambientes, aprovada pelas partes interessadas e só então implementada. Este processo reduz o risco de interrupções e garante que as equipas de suporte têm tempo para se preparar.
Gestão de releases no contexto do ITIL 4
No ITIL 4, a gestão de releases integra-se diretamente com a gestão de mudanças, que autoriza o que deve ser implementado, e com a gestão de deployment, que executa a implementação física. As três práticas trabalham em conjunto mas têm responsabilidades distintas - uma separação que o ITIL 4 tornou mais clara do que nas versões anteriores.
Ao contrário de versões mais antigas do ITIL, onde release e deployment eram frequentemente tratados como uma prática única ("Release, Control and Validation"), o ITIL 4 reconhece que em organizações com pipelines de entrega contínua, a separação clara de responsabilidades melhora a agilidade sem sacrificar o controlo.
Release vs versão - terminologia a conhecer
Em PT-PT, os termos "release" e "versão" são frequentemente usados como sinónimos, mas têm nuances diferentes no contexto ITIL. Uma versão refere-se tipicamente ao número identificador (v2.1, v3.0), enquanto a release é o conjunto de componentes e o processo de entrega associado. Um único número de versão pode corresponder a múltiplas releases em ambientes diferentes.
Tipos de release
Classificar releases por tipo ajuda as equipas a calibrar o nível de planeamento, teste e aprovação necessário. O ITIL 4 não impõe uma taxonomia rígida, mas a prática generalizada distingue três categorias principais.
| Tipo | Âmbito das alterações | Risco típico | Ciclo de aprovação | Exemplos práticos |
|---|---|---|---|---|
| Major release | Novas funcionalidades significativas, redesenho de arquitetura, mudança de plataforma | Alto | CAB completo, múltiplos testes de aceitação, comunicação formal | Lançamento de novo módulo ERP, migração de sistema legacy |
| Minor release | Melhorias incrementais, pequenas funcionalidades, correções não críticas | Médio | Aprovação simplificada, testes de regressão | Atualização de interface, novo relatório, ajuste de regras de negócio |
| Emergency release / Patch | Correção crítica de segurança ou bug de alta severidade | Variável | Processo acelerado, ECAB ou aprovação antecipada | Patch de segurança urgente, correção de crash em produção |
Como classificar releases na prática
A classificação deve ser definida antecipadamente na política de release da organização, não caso a caso. Critérios comuns incluem: número de componentes alterados, impacto esperado nos utilizadores, alterações à arquitetura, e necessidade de downtime. Uma política clara evita debates durante a fase de planeamento.
Algumas organizações adicionam uma quarta categoria - standard release - para alterações pré-aprovadas e de baixo risco que seguem um procedimento totalmente automatizado sem revisão manual, semelhante ao conceito de standard change na gestão de mudanças.
O processo de release management
O processo de gestão de releases segue cinco fases sequenciais. Em organizações com práticas DevOps maduras, estas fases podem ser altamente automatizadas, mas os princípios mantêm-se independentemente do grau de automação.
Planeamento da release
Define-se o âmbito (quais as mudanças incluídas), o calendário de entrega, os recursos necessários, os ambientes alvo e os critérios de aceitação. O plano de release serve de contrato interno entre desenvolvimento, operações e negócio.
Construção e testes
Os componentes são desenvolvidos ou configurados e submetidos a testes progressivos: unitários, integração e aceitação pelo utilizador (UAT). Cada ambiente de teste simula as condições de produção com maior fidelidade.
Preparação do deployment
Cria-se o plano de deployment detalhado com procedimentos passo a passo, critérios de go/no-go, plano de rollback e comunicações aos stakeholders. As aprovações necessárias são obtidas antes da janela de implementação.
Execução do deployment
A release é implementada no ambiente de produção seguindo o plano aprovado. A equipa de operações monitoriza o sistema durante e imediatamente após a implementação para detetar anomalias.
Validação e encerramento
Confirma-se que a release funciona conforme esperado através de testes de smoke e monitorização pós-deployment. Recolhe-se feedback dos utilizadores, documenta-se o resultado e conduz-se uma revisão pós-implementação.
Critérios de go/no-go
Um dos elementos mais importantes do processo é definir, antes do deployment, quais os critérios que determinam se a release avança ou é adiada. Critérios típicos de go incluem: todos os testes de aceitação aprovados, plano de rollback testado, documentação atualizada, equipa de suporte informada e janela de manutenção confirmada com os utilizadores afetados. Se algum critério não for cumprido, a decisão correcta é adiar - por mais pressão que exista para avançar.
Integração com a gestão de mudanças
Cada release deve ter uma mudança correspondente aprovada pelo processo de gestão de mudanças. Em alguns modelos organizacionais, uma única RFC (Request for Change) cobre toda a release; noutros, cada componente tem a sua RFC. A escolha depende da granularidade de rastreabilidade que a organização precisa.
Release vs deployment management
O ITIL 4 separou formalmente estas duas práticas, algo que nas versões anteriores estava agrupado. Esta distinção tem implicações práticas importantes para equipas que adotam DevOps ou entrega contínua.
| Dimensão | Release Management | Deployment Management |
|---|---|---|
| Foco principal | Preparar e empacotar as alterações prontas para produção | Mover fisicamente as alterações para o ambiente alvo |
| Responsabilidade típica | Release manager, product owner, equipa de testes | Equipa de operações, DevOps engineer, plataforma CI/CD |
| Momento de atuação | Antes do deployment - planeamento, testes, aprovação | Durante e após o deployment - execução, validação técnica |
| Artefactos produzidos | Plano de release, notas de versão, critérios de aceitação | Runbook de deployment, scripts, logs de execução |
| Decisão de avançar | Aprovação baseada em testes e critérios de negócio | Execução técnica do plano aprovado |
| Paralelismo possível | Pode preparar múltiplas releases em simultâneo | Executa deployments de forma sequencial ou paralela por ambiente |
Porque a distinção importa na prática
Em pipelines de entrega contínua (CI/CD), o deployment pode acontecer dezenas de vezes por dia de forma automatizada. Mas a decisão de o que entra em produção - e quando - continua a ser uma decisão de release management. Feature flags, por exemplo, permitem que código seja deployado sem ser ativado: o deployment já aconteceu, mas a release (ativação da funcionalidade para os utilizadores) acontece numa decisão separada e controlada.
Esta separação torna-se crítica quando uma organização precisa de responder a uma emergência: o deployment pode ser revertido tecnicamente em minutos, mas a decisão de reverter é uma decisão de release management que envolve avaliar impacto, comunicar com stakeholders e documentar o incidente.
Ambientes de release
Uma gestão de releases eficaz depende de uma cadeia de ambientes bem definida que permite testar progressivamente em condições cada vez mais próximas da produção.
Cadeia de ambientes típica
Paridade entre ambientes
Um dos problemas mais comuns em release management é a falta de paridade entre staging e produção. Se o staging tem versões diferentes de bibliotecas, configurações distintas ou volumes de dados completamente diferentes, os testes em staging têm valor limitado. O princípio de "keep staging as close to production as possible" deve ser uma prioridade.
Em ambientes cloud, Infrastructure as Code (IaC) com Terraform ou Pulumi facilita enormemente a paridade entre ambientes, pois a mesma definição é usada para criar infraestruturas equivalentes em cada tier. Esta é uma das razões pelas quais a integração entre release management e práticas DevOps é cada vez mais natural.
Acesso e controlo de ambientes
Cada ambiente deve ter políticas de acesso bem definidas. Em produção, o acesso deve ser restrito e auditado. As alterações manuais a produção fora do processo de release - os chamados "hot fixes feitos à mão" - são uma fonte comum de problemas que depois são difíceis de diagnosticar. Toda e qualquer alteração a produção deve passar pelo processo formal, mesmo que seja urgente.
Planos de rollback
Um plano de rollback descreve os passos para reverter uma release ao estado anterior caso algo corra mal. Preparar este plano antes de cada release - e não durante uma crise - é uma das práticas mais importantes e frequentemente negligenciadas.
Porque o rollback é frequentemente subestimado
Quando um deployment corre bem, o plano de rollback nunca é usado e parece ter sido trabalho desnecessário. Quando corre mal, é o único documento que interessa. Organizações que tratam o plano de rollback como opcional descobrem invariavelmente o seu valor da pior forma possível.
Situações que justificam rollback imediato
Erros críticos que afetam a disponibilidade do serviço; degradação de performance acima dos limites acordados; falhas de segurança descobertas pós-deployment; incumprimento dos critérios de aceitação definidos no plano.
Critérios de trigger bem definidos
O plano deve especificar claramente: quem toma a decisão de rollback, com base em que métricas (taxa de erros, latência, alertas críticos) e dentro de que janela temporal. Critérios vagos geram hesitação quando o tempo conta.
Elementos de um bom plano de rollback
Responsável pela decisão; passos técnicos numerados; estimativa de tempo de rollback; verificações pós-rollback para confirmar o restauro; comunicações a enviar; lista de contactos de emergência. Deve ser testado sempre que possível em staging.
Rollback vs Forward fix
Por vezes reverter é mais complexo do que corrigir em frente (forward fix), especialmente quando existem migrações de base de dados ou integrações com terceiros que não suportam reversão. A escolha entre rollback e forward fix deve ser uma decisão consciente, não uma improvisação.
Rollback em contextos de entrega contínua
Em pipelines CI/CD com múltiplos deployments por dia, o conceito de rollback evolui. Feature flags permitem desativar uma funcionalidade sem reverter o código. Blue/green deployments e canary releases facilitam um rollback quase instantâneo ao redirecionar tráfego. Estas técnicas reduzem o risco mas não eliminam a necessidade de um plano - mudam apenas a forma como é executado.
Boas práticas de release management
Automatizar o pipeline de release
Pipelines CI/CD automatizados reduzem erros manuais, aumentam a consistência e permitem releases mais frequentes com menor risco. A automação não elimina o controlo - formaliza-o.
Testar cedo e com frequência
Detetar defeitos em DEV é exponencialmente mais barato do que em produção. Testes automatizados de regressão em cada commit garantem que alterações novas não quebram funcionalidade existente.
Usar canary releases
Dirigir uma percentagem pequena do tráfego para a nova versão antes do rollout completo permite validar o comportamento em produção com impacto limitado. Se algo correr mal, o blast radius é reduzido.
Utilizar feature flags
Feature flags permitem separar deployment de release: o código entra em produção inativo e é ativado gradualmente ou por segmento de utilizadores. Isto dá controlo total sobre a exposição de novas funcionalidades.
Documentar release notes com qualidade
Notas de versão claras - escritas para os utilizadores, não só para técnicos - reduzem chamadas ao service desk e facilitam o trabalho das equipas de suporte. Incluir o que mudou, o que foi corrigido e eventuais impactos esperados.
Realizar revisão pós-release
Após cada release significativa, conduzir uma revisão breve: o que correu bem, o que podia ter corrido melhor, que métricas de sucesso foram atingidas. Este ciclo de aprendizagem contínua é alinhado com a prática de melhoria contínua do ITIL 4.
Descarregue a template de plano de release
Modelo profissional com calendário, testes, critérios de aceitação e rollback, em Word.
Ver todas as templates ITSMPerguntas frequentes
Uma release é um conjunto de alterações autorizadas a um serviço de TI que são testadas e implementadas em conjunto. Pode incluir hardware, software, documentação e processos. A release representa uma versão coerente e testada de um serviço ou componente, pronta para ser entregue ao utilizador final.
A release refere-se ao conjunto de mudanças prontas para produção - o processo de preparação, teste e aprovação. O deployment é o acto de mover essas mudanças para o ambiente de produção. No ITIL 4, são práticas separadas. Uma release pode ser deployada de forma faseada; um deployment pode incluir apenas parte de uma release.
Um plano de rollback descreve os passos para reverter uma release caso algo corra mal durante ou após o deployment. Deve ser definido antes de cada release e testado quando possível. Inclui: quem toma a decisão de reverter, os critérios que a desencadeiam, os passos técnicos numerados e as verificações pós-rollback para confirmar o restauro do serviço.
Os tipos mais comuns são: major release (alterações significativas à arquitetura ou novas funcionalidades de grande âmbito), minor release (melhorias incrementais e correções menores) e emergency release (correções críticas de segurança ou bugs de alta severidade que não podem esperar pelo ciclo normal). Cada tipo requer um nível diferente de planeamento e aprovação.
Métricas comuns incluem: taxa de sucesso de releases (percentagem de releases sem rollback), número de incidentes pós-release nas primeiras 24-72 horas, tempo de deployment (lead time from commit to production), frequência de rollbacks, cumprimento do calendário previsto e satisfação dos utilizadores após a release. O DORA metrics framework (deployment frequency, lead time, change failure rate, time to restore) é uma referência útil para organizações com práticas DevOps.
Domine a gestão de releases
Aprenda release management e todas as práticas ITIL com a certificação ITIL 4 Foundation.
Peça informações