Release management

O release manager consolida os RFCs autorizados pelo change enablement, define o âmbito da release, estabelece o calendário e aloca os recursos necessários. Uma release pode ser do tipo major (grandes alterações de produto), minor (novas funcionalidades), patch (correcções de defeitos) ou emergency (correcções de segurança urgentes). O plano de release deve contemplar também o plano de rollback em caso de falha.

Passos chave

• Consolidar as mudanças autorizadas a incluir na release
• Classificar o tipo de release (major, minor, patch, emergency)
• Definir calendário: janelas de deployment, freeze periods
• Identificar dependências com outras releases ou sistemas
• Elaborar plano de rollback e critérios de activação
• Comunicar o plano aos stakeholders relevantes

O release manager e a equipa de desenvolvimento identificam e documentam todos os componentes que integram a release: artefactos de código, configurações, scripts de base de dados, actualizações de documentação e dependências de infraestrutura. A distinção entre release e deployment é relevante aqui: a release pode tornar-se disponível simultaneamente com o deployment (modelo push) ou ser disponibilizada para instalação pelo utilizador (modelo pull).

Passos chave

• Listar todos os componentes incluídos e respectivas versões
• Documentar dependências e pré-requisitos de instalação
• Definir modelo de release: big bang, phased, push ou pull
• Identificar sistemas e CIs afectados na CMDB
• Criar release note com descrição das alterações

A equipa de operações prepara os ambientes necessários para a pipeline de release: desenvolvimento, teste/QA, staging (pré-produção) e produção. A paridade entre staging e produção é fundamental para que os testes sejam representativos. Em contextos CI/CD, esta actividade é parcialmente automatizada através de infraestrutura como código (IaC).

Passos chave

• Validar a configuração dos ambientes de teste e staging
• Garantir paridade de configuração entre staging e produção
• Preparar dados de teste representativos (anonimizados)
• Verificar disponibilidade de ferramentas de monitorização
• Configurar pipelines de CI/CD se aplicável

A equipa de desenvolvimento constrói o pacote de release a partir das branches de código consolidadas, integrando todos os componentes definidos. Em ambientes com integração contínua (CI), este processo é automatizado: cada commit despoleta um build automático, testes unitários e análise de qualidade de código. O artefacto resultante é versionado e armazenado num repositório de artefactos.

Passos chave

• Fazer merge das branches de funcionalidade para a branch de release
• Executar o processo de build e compilação
• Executar testes unitários e de integração automáticos
• Realizar análise estática de código (SonarQube ou equivalente)
• Versionar e armazenar o artefacto no repositório
• Verificar que o artefacto é reproduzível (build determinístico)

O pacote é submetido a um conjunto de testes em ambiente de staging: smoke tests para verificação básica de funcionamento, testes de regressão para garantir que funcionalidades existentes não foram afectadas, testes de aceitação pelo utilizador (UAT) e, quando relevante, testes de carga e performance. Os resultados alimentam a decisão go/no-go da actividade seguinte.

Tipos de testes aplicados

• Smoke tests: validação básica de que o sistema arranca e funciona
• Testes de regressão: verificação de que funcionalidades existentes não regrediram
• UAT (User Acceptance Testing): validação pelo negócio ou utilizadores-chave
• Testes de performance: validação de tempos de resposta e capacidade
• Testes de segurança: verificação de vulnerabilidades introduzidas

O release manager convoca uma reunião de go/no-go com os stakeholders relevantes para avaliar os resultados dos testes, o nível de risco e a adequação do calendário. A decisão é baseada em critérios pré-definidos: taxa de defeitos aberta, cobertura de testes, aprovação do negócio e janela de deployment disponível. Uma decisão no-go implica o retorno à fase de build ou testes para correcção dos problemas identificados.

Critérios de avaliação

• Nenhum defeito crítico ou bloqueante em aberto
• Taxa de aprovação dos testes de aceitação acima do limiar definido
• Plano de rollback validado e testado
• Janela de deployment confirmada e equipa disponível
• Aprovação formal dos service owners afectados

A equipa de operações executa o deployment do pacote aprovado em produção, seguindo o plano de deployment definido. Existem várias estratégias possíveis: blue-green deployment (dois ambientes idênticos com switch de tráfego), canary release (distribuição progressiva a uma percentagem de utilizadores), rolling deployment (substituição gradual de instâncias) ou deployment directo. A escolha da estratégia depende do risco, criticidade e capacidade técnica da organização.

Estratégias de deployment

• Blue-green: dois ambientes paralelos, switch de tráfego instantâneo com rollback imediato
• Canary: release progressiva a uma percentagem crescente de utilizadores
• Rolling: substituição gradual de instâncias com zero downtime
• Recreate: substituição directa com janela de manutenção

Imediatamente após o deployment, a equipa de operações monitoriza o ambiente de produção para confirmar que o sistema funciona dentro dos parâmetros normais. Esta fase de early life support inclui verificação de métricas de saúde (error rate, latência, disponibilidade), comparação com baselines pré-deployment e prontidão para activar o rollback se necessário. O período de monitorização intensiva dura tipicamente entre 30 minutos e 24 horas, dependendo da criticidade da release.

Métricas de saúde a monitorizar

• Taxa de erros: aumento anormal de erros 4xx e 5xx
• Latência: tempos de resposta comparados com baseline
• Disponibilidade: percentagem de uptime do serviço
• Saturação: utilização de CPU, memória e disco
• Volume de negócio: transacções por segundo, logins, conversões

Com a release estável em produção, o release manager comunica formalmente a entrega aos utilizadores e partes interessadas. A comunicação inclui o resumo das novas funcionalidades, alterações de comportamento relevantes, instruções de utilização e canais de suporte. A documentação operacional e os manuais de utilizador são actualizados e a equipa de service desk é informada para estar preparada para questões relacionadas com a release.

Passos chave

• Enviar release notes aos utilizadores e stakeholders
• Actualizar portais de self-service e base de conhecimento
• Informar o service desk sobre as alterações e possíveis questões
• Actualizar documentação técnica e operacional
• Actualizar o catálogo de serviços se aplicável

Após um período de estabilização, o release manager conduz uma revisão pós-release com as equipas envolvidas. O objectivo é avaliar o desempenho do processo, medir o cumprimento dos critérios de sucesso definidos no plano e identificar oportunidades de melhoria para releases futuras. As lições aprendidas são documentadas e partilhadas com a organização.

Passos chave

• Comparar métricas reais com os objectivos definidos no plano
• Documentar o que correu bem e o que pode ser melhorado
• Registar defeitos encontrados em produção pós-release
• Identificar melhorias ao processo para a próxima release
• Actualizar templates e checklists com base nas lições aprendidas
• Partilhar o relatório com a liderança e equipas de desenvolvimento