Deployment management
Processo end-to-end com pipelines CI/CD, Infrastructure as Code, modelos de deployment (blue-green, canary, rolling), rollback e métricas
Descarregar pack completoÂmbito e objectivos
Mover componentes novos ou alterados — hardware, software, documentação, processos ou qualquer outro elemento — para ambientes controlados de forma segura, repetível e rastreável, conforme a definição ITIL.
Release aprovada pelo release manager, mudança autorizada pelo change enablement, patch de segurança urgente ou actualização de infraestrutura planeada.
Desde a preparação do deployment até à execução técnica, validação pós-deployment e rollback se necessário. Abrange todos os ambientes: desenvolvimento, teste, staging, pré-produção e produção.
Autorização de mudanças (change enablement), planeamento e coordenação de releases (release management) e desenvolvimento de software. O deployment executa — não decide o que vai a produção.
Componentes deployados em produção com validação confirmada, registos de deployment actualizados na CMDB, relatório de execução documentado e, em caso de falha, rollback executado com incidente registado.
Deployment vs release management
Em ITIL, estas duas práticas são complementares mas distintas. A confusão entre ambas é uma das causas mais frequentes de falhas de governança em ambientes DevOps.
| Dimensão | Release management | Deployment management |
|---|---|---|
| Foco | Planear e coordenar o QUE vai a produção | Executar tecnicamente o COMO chega lá |
| Decisão | Autoriza o conteúdo da release | Executa a transferência de componentes |
| Stakeholders | Negócio, product owner, change manager | DevOps, ops, deployment manager |
| Timing | Antes do deployment (planeamento) | Execução técnica da release aprovada |
| Output | Release aprovada, comunicação ao negócio | Componentes em produção, validação técnica |
Modelos de deployment
| Modelo | Descrição | Vantagens | Riscos |
|---|---|---|---|
| Big bang | Todos os componentes deployados de uma só vez para todos os utilizadores | Simples, sem ambiguidade de versões | Risco elevado; rollback complexo |
| Phased (faseado) | Deployment gradual por grupos de utilizadores ou regiões | Risco controlado, feedback progressivo | Coexistência de versões, maior duração |
| Blue-green | Dois ambientes idênticos; tráfego comutado entre eles | Rollback imediato (comutação de tráfego) | Custo de infraestrutura duplicada |
| Canary | Nova versão exposta a uma pequena percentagem de tráfego real | Validação em produção com risco mínimo | Complexidade de routing; monitorização intensiva |
| Rolling | Instâncias actualizadas progressivamente, sem downtime | Zero downtime; reversível por instância | Coexistência temporária de versões |
| Continuous deployment | Cada commit aprovado é deployado automaticamente para produção | Ciclos muito curtos; feedback imediato | Requer testes automatizados robustos |
Diagrama do processo
Diagrama BPMN simplificado do processo de deployment management (3 swimlanes: Release manager, Deployment manager, DevOps/Ops). Percorra horizontalmente em dispositivos móveis.
Actividades macro
| # | Actividade | Responsável | Input | Output |
|---|---|---|---|---|
| 1 | Planeamento do deployment | Deployment manager | Release aprovada, RFC autorizado | Plano de deployment (janela, modelo, rollback) |
| 2 | Preparação de ambientes | Equipa DevOps/Ops | Plano de deployment, IaC scripts | Ambientes configurados e validados |
| 3 | Preparação do pacote de deployment | Equipa DevOps/Ops | Artefactos do build, manifests, configurações | Pacote de deployment validado e versionado |
| 4 | Validação pré-deployment | Deployment manager / DevOps | Checklist pré-deploy, testes de fumo | Go/No-go decision documentada |
| 5 | Execução do deployment | Equipa DevOps/Ops | Pacote aprovado, pipeline CI/CD | Componentes deployados no ambiente alvo |
| 6 | Verificação pós-deployment | Deployment manager / DevOps | Componentes deployados, health checks | Confirmação de sucesso ou trigger de rollback |
| 7 | Rollback (se necessário) | Equipa DevOps/Ops | Falha detectada, procedimento de rollback | Ambiente restaurado à versão anterior; incidente registado |
| 8 | Documentação e registo | Deployment manager | Resultado do deployment, registos de execução | CMDB actualizada, deployment record criado |
| 9 | Revisão e melhoria | Deployment manager / Release manager | Métricas do deployment, lições aprendidas | Acções de melhoria identificadas, processo actualizado |
Descrição detalhada das actividades
O deployment manager define a janela de deployment, o modelo a utilizar (big bang, phased, blue-green, canary, rolling), as dependências entre componentes, o plano de comunicação às partes interessadas e o procedimento de rollback. O planeamento é a actividade com maior impacto na taxa de sucesso dos deployments.
Elementos do plano
- Janela de deployment: horário de menor impacto para o negócio (normalmente fora do horário de pico)
- Modelo de deployment selecionado com justificação documentada
- Dependências de outros sistemas, serviços ou deployments
- Plano de comunicação: stakeholders, canais, timing
- Critérios de sucesso e limiares para rollback automático
- Procedimento de rollback passo a passo com responsável designado
A preparação de ambientes com IaC garante que todos os ambientes (dev, test, staging, pre-prod, prod) são criados e configurados de forma idêntica e repetível, eliminando a variabilidade manual e os problemas de "funciona no meu ambiente". Ferramentas como Terraform, Ansible e Puppet são as mais utilizadas.
Ferramentas comuns
- Terraform: provisionamento de infraestrutura cloud (AWS, Azure, GCP) declarativo
- Ansible: gestão de configuração e orquestração sem agente
- Puppet / Chef: gestão de configuração baseada em agente, ideal para ambientes grandes
- Helm: gestão de pacotes Kubernetes para aplicações containerizadas
- CloudFormation / Bicep: IaC nativo AWS e Azure respectivamente
O pipeline CI/CD automatiza o processo de build, teste e deployment, reduzindo o erro humano e acelerando o tempo de entrega. A integração contínua (CI) valida cada commit; a entrega/deployment contínuo (CD) leva automaticamente o artefacto validado ao ambiente alvo.
Plataformas principais
- Jenkins: open source, altamente extensível, ideal para ambientes on-premise
- GitLab CI/CD: integrado no repositório, pipeline-as-code com .gitlab-ci.yml
- GitHub Actions: nativo GitHub, excelente para projectos cloud-native
- Azure DevOps Pipelines: integração nativa com ecossistema Microsoft
- ArgoCD / Flux: GitOps para Kubernetes, sincronização declarativa
Stages típicos do pipeline
- Build: compilação e criação do artefacto (container image, package)
- Test: testes unitários, integração, segurança (SAST/DAST)
- Stage: deployment em ambiente de staging para validação funcional
- Approval: gate manual ou automático antes de produção
- Production: deployment com estratégia definida (canary, rolling, etc.)
Antes de qualquer deployment em produção, executa-se uma checklist estruturada que valida todas as pré-condições. Uma decisão go/no-go formal é documentada com o responsável identificado. Esta actividade é crítica para evitar deployments em condições adversas.
Checklist pré-deployment
- Release aprovada pelo release manager e RFC autorizado pelo change enablement
- Artefactos de build disponíveis no repositório com hash verificado
- Testes automatizados passados (unitários, integração, regressão)
- Ambientes de destino disponíveis e configurados
- Janela de deployment confirmada e partes interessadas notificadas
- Plano de rollback testado e responsável disponível
- Monitorização activa e alertas configurados
A execução do deployment segue a estratégia definida no planeamento. Cada estratégia tem procedimentos específicos que a equipa DevOps/Ops deve seguir rigorosamente para garantir reversibilidade e minimizar impacto.
Blue-green deployment
- Manter ambiente "blue" (actual em produção) inalterado
- Deployar versão nova no ambiente "green" (réplica idle)
- Validar "green" com tráfego de teste ou utilizadores piloto
- Comutar load balancer/DNS de blue para green
- Manter blue disponível para rollback imediato por 24-48h
Canary deployment
- Deployar nova versão em subconjunto de instâncias (tipicamente 5-10%)
- Dirigir percentagem controlada de tráfego real para a versão canary
- Monitorizar métricas de erro, latência e negócio durante período definido
- Aumentar gradualmente o tráfego se métricas estiverem dentro dos limiares
- Promover para 100% ou reverter com base nos resultados
Imediatamente após o deployment, executam-se smoke tests (testes de fumo) e health checks para validar que os componentes críticos estão a funcionar. Esta verificação deve ser automatizada e ocorrer dentro de um período máximo definido (tipicamente 15-30 minutos).
Tipos de verificação
- Health check endpoints: /health, /ready — verifica que a aplicação está a responder
- Smoke tests: conjunto mínimo de testes que validam as funcionalidades críticas
- Synthetic monitoring: transacções simuladas que validam fluxos de negócio end-to-end
- Métricas de observabilidade: taxa de erro, latência p95, throughput vs. baseline
- Log analysis: verificação de logs de arranque sem erros críticos
Limiares típicos para rollback automático
- Taxa de erro HTTP 5xx superior a 1% durante 5 minutos
- Latência p95 superior a 2x o baseline durante 10 minutos
- Health check a falhar em mais de 20% das instâncias
O rollback é a capacidade de reverter um deployment para a versão anterior de forma rápida e controlada. Um bom processo de deployment é inseparável de um bom plano de rollback. A decisão de rollback deve ser tomada rapidamente — quanto mais se espera, maior o impacto.
Triggers de rollback
- Smoke tests ou health checks a falhar após deployment
- Métricas de erro ou latência a exceder limiares definidos
- Falha crítica de negócio reportada (transacções, pagamentos, autenticação)
- Rollback automático activado pelo pipeline com base em alertas
Mecanismos de rollback por estratégia
- Blue-green: redireccionamento imediato do tráfego para o ambiente blue
- Canary: redução do tráfego canary para 0% e remoção das instâncias novas
- Rolling: re-deployment da versão anterior instância a instância
- Kubernetes:
kubectl rollout undo deployment/nomereverte para a revisão anterior
Cada deployment deve gerar um registo completo que serve de auditoria, rastreabilidade e base para análise de problemas futuros. A CMDB deve ser actualizada imediatamente após um deployment bem sucedido para reflectir o estado real dos CIs em produção.
Elementos do deployment record
- Identificador único do deployment e referência ao RFC/release
- Data, hora de início e duração total
- Versão deployada (número de versão, commit hash, tag)
- Ambiente alvo e lista de CIs afectados
- Resultado: sucesso, falha ou rollback com motivo
- Responsável pela execução e aprovação
- Resultados dos smoke tests e health checks
Modelo RACI
| Actividade | Deploy. manager (DM) |
DevOps/Ops (DO) |
Release manager (RM) |
Change manager (CM) |
Service owner (SO) |
|---|---|---|---|---|---|
| Planeamento do deployment | R | C | A | C | I |
| Preparação de ambientes (IaC) | A | R | I | - | - |
| Preparação do pacote de deployment | A | R | C | - | - |
| Validação pré-deployment (go/no-go) | R | C | A | C | I |
| Execução do deployment | A | R | I | I | I |
| Verificação pós-deployment | R | C | A | - | I |
| Rollback (se necessário) | A | R | I | I | I |
| Documentação e registo (CMDB) | R | C | A | I | I |
| Revisão e melhoria | R | C | A | C | I |
Métricas e KPIs
| Métrica | Descrição | Target sugerido |
|---|---|---|
| Deployment frequency | Frequência com que deployments chegam a produção — indicador DORA de velocidade de entrega | Diário a semanal |
| Deployment success rate | Percentagem de deployments concluídos com sucesso sem rollback nem incidente | > 95% |
| MTTR (falhas de deployment) | Tempo médio para restaurar o serviço após um deployment falhado (rollback ou correcção) | < 30 min |
| Lead time to deploy | Tempo desde o commit aprovado até ao deployment em produção — indicador DORA de velocidade | < 1 dia |
| Rollback rate | Percentagem de deployments que requerem rollback — indica qualidade dos testes e do planeamento | < 5% |
| Deployment duration | Tempo médio de execução de um deployment completo, do início à validação pós-deploy | < 30 min |
| Change failure rate | Percentagem de mudanças/deployments que causam incidentes ou degradação em produção — indicador DORA de estabilidade | < 15% |
Interfaces com outros processos
Release management
Fornece a release aprovada para deployment. O release manager define o WHAT; o deployment manager executa o HOW.
Change enablement
O RFC autorizado é pré-condição para qualquer deployment. O change manager valida que a mudança foi aprovada antes da execução.
CMDB
Após deployment bem sucedido, os CIs afectados são actualizados na CMDB com a nova versão, data e responsável pela mudança.
Monitorização e eventos
O deployment activa verificações de monitorização pós-deploy. Alertas de degradação pós-deployment são o trigger principal para rollback.
Build / Pipeline CI
Os artefactos gerados pelo pipeline de integração contínua (imagens Docker, packages, binários) são os inputs para a execução do deployment.
Gestão de incidentes
Falhas de deployment que causam interrupção de serviço geram automaticamente um incidente. O registo de deployment serve de contexto para a investigação.
Descarregar o pack completo
Inclui o processo documentado, plano de deployment, checklist go/no-go, modelo RACI em Excel e registo de deployment.