Coordenando Deployments Através de Equipes

Deployments modernos frequentemente abrangem múltiplos serviços, equipes e repositórios. Deployments não coordenados levam a falhas de integração, downtime e apontar o dedo. O GitScrum ajuda a coordenar atividades de deployment para que todos saibam o que está sendo implantado, quando e quais dependências existem.

Desafios de Deployment

Modelo de Coordenação de Deployment

Abordagem Release Train

ESTRUTURA RELEASE TRAIN
═══════════════════════

RELEASE: v2.5.0 (20 de março, 2024)
├── Release Manager: @sarah
├── Janela Deploy: 14:00-16:00 UTC
└── Janela Rollback: Até 18:00 UTC

SERVIÇOS INCLUÍDOS:
┌─────────────────────────────────────────────────────────┐
│  Serviço         │ Versão │ Equipe  │ Dependências     │
├─────────────────────────────────────────────────────────┤
│  API Gateway     │ 1.8.0  │ Infra   │ Nenhuma (primeiro)│
│  Auth Service    │ 2.3.0  │ Backend │ API Gateway      │
│  User Service    │ 3.1.0  │ Backend │ Auth Service     │
│  Web Frontend    │ 4.5.0  │ Frontend│ Todos backends   │
│  Mobile Backend  │ 2.0.0  │ Mobile  │ User Service     │
└─────────────────────────────────────────────────────────┘

ORDEM DE DEPLOYMENT:
1. API Gateway (14:00)
2. Auth Service (14:10)
3. User Service (14:20)
4. Mobile Backend (14:30)
5. Web Frontend (14:40)

Visualização de Dependências

GRÁFICO DE DEPENDÊNCIA DE DEPLOYMENT
════════════════════════════════════

    ┌─────────────────┐
    │   API Gateway   │
    │   (Deploy 1st)  │
    └────────┬────────┘
             │
    ┌────────┴────────┐
    ▼                 ▼
┌─────────┐     ┌───────────┐
│  Auth   │     │  Logging  │
│ Service │     │  Service  │
└────┬────┘     └───────────┘
     │
┌────┴────┐
▼         ▼
┌─────────┐     ┌─────────────┐
│  User   │────▶│   Mobile    │
│ Service │     │   Backend   │
└────┬────┘     └─────────────┘
     │
     ▼
┌─────────────┐
│     Web     │
│  Frontend   │
│ (Deploy Last)│
└─────────────┘

Checklist Pré-Deployment

Verificação de Prontidão

CHECKLIST PRÉ-DEPLOYMENT
════════════════════════

CADA EQUIPE CONFIRMA:

[Equipe API Gateway]
- [x] Todos PRs mesclados na branch release
- [x] Testes passando no CI
- [x] Staging testado e verificado
- [x] Migrações de banco prontas
- [x] Mudanças de config documentadas
- [x] Procedimento de rollback documentado
- [x] Engenheiro on-call identificado
Status: PRONTO ✓

[Equipe Auth Service]
- [x] Todos PRs mesclados na branch release
- [x] Testes passando no CI
- [ ] Staging testado e verificado ⚠
- [x] Migrações de banco prontas
- [x] Mudanças de config documentadas
- [x] Procedimento de rollback documentado
- [x] Engenheiro on-call identificado
Status: BLOQUEADO - Verificação staging pendente

[Equipe User Service]
...

Reunião Go/No-Go

CHECKLIST GO/NO-GO
══════════════════

REUNIÃO: 13:30 UTC (30 min antes do deploy)
PARTICIPANTES: Release manager + leads de equipe

CHECKLIST:
├── Todos os serviços mostram status PRONTO?
├── Todas as verificações staging completas?
├── Todos os engenheiros on-call disponíveis?
├── Canais de comunicação prontos?
├── Dashboards de monitoramento abertos?
├── Suporte ao cliente informado?
├── Scripts de rollback testados?
└── Scripts de deploy prontos?

DECISÃO:
├── GO: Prosseguir com deployment
├── NO-GO: Abortar, reagendar
└── PARCIAL: Implantar subconjunto (com plano)

Execução de Deployment

Fluxo de Comunicação

COMUNICAÇÃO DE DEPLOYMENT
═════════════════════════

CANAL: #release-2.5.0

T-30 min:
├── @channel: Reunião Go/No-Go começando
└── Decisão: GO ✓

T-0 (14:00):
├── @channel: 🚀 Deployment começando
├── @infra: Iniciando deploy API Gateway
└── Status: Em Progresso

T+10 min:
├── @infra: ✓ API Gateway implantado, smoke tests passando
├── @backend: Iniciando deploy Auth Service
└── Status: API Gateway ✓, Auth Em Progresso

T+20 min:
├── @backend: ✓ Auth Service implantado
├── @backend: Iniciando deploy User Service
└── Status: API ✓, Auth ✓, User Em Progresso

... (continuar para cada serviço)

T+45 min:
├── @channel: ✓ Todos os serviços implantados
├── @channel: Executando verificação final
└── Status: Verificação Em Progresso

T+50 min:
├── @channel: ✅ Release v2.5.0 completo
├── Todos os smoke tests passando
├── Monitoramento parece bom
└── Status: SUCESSO

Dashboard em Tempo Real

DASHBOARD DE DEPLOYMENT
═══════════════════════

Release: v2.5.0 | Iniciado: 14:00 | Status: EM PROGRESSO

┌─────────────────────────────────────────────────────────┐
│  Serviço         │ Status      │ Tempo   │ Saúde       │
├─────────────────────────────────────────────────────────┤
│  API Gateway     │ ✓ Completo  │ 8 min   │ ✓ Saudável  │
│  Auth Service    │ ✓ Completo  │ 7 min   │ ✓ Saudável  │
│  User Service    │ ⏳ Implantando│ 3 min  │ ⏳ Pendente │
│  Mobile Backend  │ ⏸ Aguardando│ -       │ -           │
│  Web Frontend    │ ⏸ Aguardando│ -       │ -           │
└─────────────────────────────────────────────────────────┘

Logs | Métricas | Rollback

ATIVIDADE ATUAL:
├── User Service: Rolling update 3/5 pods
├── Aguardando: Mobile Backend, Web Frontend
└── ETA: 15 minutos restantes

Procedimentos de Rollback

Plano de Rollback

PROCEDIMENTOS DE ROLLBACK
═════════════════════════

GATILHOS DE ROLLBACK:
├── Taxa de erro > 1% por 2 minutos
├── Latência P99 > 2x baseline
├── Funcionalidade crítica quebrada
├── Problema de integridade de dados detectado
└── Decisão de lead de equipe

ORDEM DE ROLLBACK (reverso do deploy):
1. Web Frontend → v4.4.0
2. Mobile Backend → v1.9.0
3. User Service → v3.0.0
4. Auth Service → v2.2.0
5. API Gateway → v1.7.0

ESPECÍFICO POR SERVIÇO:
──────────────────────────────────────
API Gateway:
Comando: kubectl rollout undo deployment/api-gateway
Verificar: curl https://api/health
Tempo: ~2 min

Auth Service:
Comando: kubectl rollout undo deployment/auth
Verificar: curl https://auth/health
Tempo: ~2 min
Banco: Sem necessidade de rollback de migração
──────────────────────────────────────

Rollback Parcial

CENÁRIO DE ROLLBACK PARCIAL
═══════════════════════════

SITUAÇÃO: User Service causando erros
DECISÃO: Fazer rollback User Service, manter outros

AÇÕES:
1. Parar deployments adicionais
2. Fazer rollback User Service
3. Verificar Auth Service ainda funciona
4. Verificar API Gateway ainda funciona
5. Comunicar status

PÓS-ROLLBACK:
├── Documentar o que falhou
├── Corrigir e re-testar
├── Agendar novo deployment
└── Post-mortem se necessário

Rastreamento de Release GitScrum

Estrutura de Tarefa de Release

TAREFA DE RELEASE NO GITSCRUM
════════════════════════════

PAI: Release v2.5.0
├── Vence: 20 de março, 2024
├── Proprietário: Release Manager
├── Rótulos: release, production
└── Milestone: Release Q1 2024

TAREFAS FILHAS:
├── [Infra] API Gateway v1.8.0
├── [Backend] Auth Service v2.3.0
├── [Backend] User Service v3.1.0
├── [Frontend] Web Frontend v4.5.0
├── [Mobile] Mobile Backend v2.0.0
├── [QA] Verificação pré-release
├── [Ops] Execução de deployment
└── [Ops] Monitoramento pós-deployment

CHECKLIST NO PAI:
├── [ ] Todos os serviços verificados em staging
├── [ ] Reunião Go/No-Go completa
├── [ ] Todas as equipes confirmaram prontas
├── [ ] Deploy completo
├── [ ] Smoke tests passando
├── [ ] Monitoramento verificado
└── [ ] Notas de release publicadas

Melhores Práticas

Para Coordenação de Deployment

1. Fonte única da verdade — Um lugar para status de deploy
2. Propriedade clara — Release manager dirige
3. Ordem definida — Dependências respeitadas
4. Ritmo de comunicação — Atualizações em cada milestone
5. Rollback pronto — Sempre tenha um plano B

Anti-Padrões

ERROS DE COORDENAÇÃO DE DEPLOYMENT:
✗ Equipes implantam independentemente
✗ Sem ordem de dependência
✗ Deploys silenciosos (sem comunicação)
✗ Sem plano de rollback
✗ Pulando check go/no-go
✗ Sem verificação pós-deploy
✗ Deploys herói (uma pessoa faz tudo)

Soluções Relacionadas

• Configurando fluxos de trabalho de gerenciamento de release
• Configurando gates de qualidade para releases
• Coordenando desenvolvimento de recursos cross-funcionais