Operações e Gerenciamento de → Ciclos de lançamentos e atualizações

Ciclos de lançamentos e atualizações

1) Destino

• reduz a incerteza e o custo de coordenação,
• reduz o risco de incidentes e saques,
• sincroniza a técnica com eventos de negócios (marketing, esportes, fina. relatórios),
• aumenta o comando throughput sem crescimento de CBR (Mudança Failure Rate).

2) Modelos de lançamento: qual selecionar

1. Release Trem - slots fixos (por exemplo, w/t 10:00 EET).

Adequado para monólitos multiuso e mudanças de domínio «pesadas».

2. Contínuo Delivery (a pedido) - Cada merge que passou por quality-gates pode ir para a proda.

Adequado para microsserviças e função-flag cultural.

3. Híbrido - frentes de alimentos sobre comboios, serviços de backend «a pedido».

Critérios de escolha: maturidade de testes/viagens, dependência de parceiros externos (PSP/KYC), requisitos de complacência, tamanho da organização.

3) Calendário de lançamento e janelas

Calendário unificado (company-wide): slots de lançamento, migração de banco de dados, campanhas de marketing, grandes eventos esportivos, períodos de relatórios.
Período Freeze: janelas bem definidas quando apenas hotfix P1 é permitido (por exemplo, final de RH, Black Friday, relatórios fiscais).
Ondas regionais: primeiro mercados «quentes »/baixo tráfego, depois principais; janelas noturnas de TZ local.
Política de cruzamento: impede alterações simultâneas em um único caminho crítico (pagamentos, KYC, autorizações).

4) Ramificação e versionização

Trunk-based + short-lived branches (função do ramo ≤ 3-5 dias).
Release-ramo - apenas para trens/longas verificações; back-merge rígido em 'principal'.
SemVer: `MAJOR. MINOR. PATCH 'para bibliotecas/SDK; tags de artefatos e ambientes.
Contratos: esquemas (Avro/Protobuf) com compatibilidade back/forward; migrações de dois fases.

5) Canweers de qualidade (gates)

1. Static + SAST/DAST + Linter

2. Testes Unit/Contract/Component

3. E2E/Performance smoke (no stage)

4. Segurança/Compliance checks (segredos, licenças, políticas de território)

5. Release Candidate → assinatura, SBOM, artefatos

6. Progressive rollout com auto-gardrelas (Consulte No 7)

Todos os gates são código e política (Policy-as-Code), os resultados estão nos artefatos de lançamento.

6) Ambientes e promoções

Dave → Int → Stand → Prod, para dados: Sandbox/Data-Station.
GitOps promoções, imagens imutáveis, proibição de edição «manual» na venda.
Configuração: regiões, limites, provedores - através de configs (auditados).

7) Estratégias de abertura

Canary: 1%→5%→25%→100% (или per-region).
Blue-Green: Ambientes paralelos + mudança atômica.
Função Flags: ativadores funcionais/kill-switch; A/B и shadow.
Staged Rollout Mobile/Web: através das versões do cliente/canais de entrega (Store/OTA).

Gardrelas (auto stop): p95 latency ↑> 25%, erro%> 2%, queda de autorizações/depósitos, crescimento de charjbacks, burn-rate SLO por uma janela de 1 hora> limiar.

8) Alinhamento com empresas e parceiros

Marketing/Eventos: lançamentos de funcionalidades para campanhas com ≥ 48 h.
Associados (PSP/KYC/Game providers): slots para certificações/atualizações SDK, endpoint duplos para o período de migração.
Suporte: macros/FAQ para alterações UX, páginas de status, canais de escalação.

9) Atualizações de dados e esquemas

Additive first: primeiro adicionar, depois mudar de leitura/gravação, no final remover o antigo.
Índices e grandes migrações - janelas noturnas, batch, checkpoint e progresso.
Versionização de vitrines e dicionário de métricas: atualizações sincronizadas com lançamento, migração BI separada das janelas de venda.

10) Comunicações e artefatos

Release Note (o que/por quê/riscos/rollback) ChangeLog pelos serviços.
Invólitos de calendário para steakholders, modelos de anúncios (antes/durante/depois).

Canal War-Room para trens/grandes lançamentos, frequência de updates: P1 - cada 15-20 minutos

11) Métricas de eficiência

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
Backout Rate por tipo de alteração.
SLO Compliance% antes/depois dos lançamentos.
Release Debt: bandeiras penduradas, migrações incompletas, dependências antigas.
Business Impacto: Conversão, KYC TTV, PSP sucess, GGR/NGR drivt pela janela de lançamento.

12) Anti-pattern

Big bang: «tudo e uma vez» sem bandeiras/canarinhos.
Lançamento no pico de tráfego/evento sem exceções freeze.
Sem guarda-roupas, monitorização manual de olho.
Ramos de vida longa, fusões dolorosas e regressões ocultas.
Passos manuais em venda: não há auditoria ou previsibilidade.
Bandeiras sem TTL ou proprietários: ramificações «eternas».

13) Folhas de cheque

Antes do lançamento

• RFC/tíquete, risco e blast-radius avaliados
• Gates CI/CD ultrapassados, artefatos assinados
• Plano de abertura + critérios stop + backout pronto
• Concordância com calendário, freeze e parceiros
• Dashboards/alertas são ligados à versão, war-room criado

Durante o lançamento

• Estágios canários e auto-parar estão ativos
• Métricas p95/erro%, sinais de negócio (auth, KYC, PSP) no monitor
• Comunicações programadas, o status da página é atualizado

Após lançamento

• Release Notas e ChangeLog publicadas
• Bandeiras removidas/exceções temporárias (TTL)
• Pós-mortem em desvios ≤ 5 escravo. dias
• Playbooks e documentação atualizados

14) Mini-modelos

• Data/hora: W, 10: 00-12: 00 EET
• Distrito: EU (10%→50%→100%) e LATAM (10%→100%)
• Critérios de parar: erro%> 2% 10 min, p95> + 25% 10 min, PSP sucess <97%
• Backout: mudança de tráfego para versão anterior + reversão de bandeiras
• Contatos @ RelEng, @ SRE-on-call, @ Apoio

• O que há de novo/Porquê
• Impacto sobre usuários e parceiros
• Riscos e limitações conhecidas
• Plano de abertura/Critérios parados/Backout
• Métricas para monitorização
• Contatos e canais de suporte

15) Integração com disciplinas vizinhas

Gerenciamento de alterações: classificação padrão/normal/emergency, FAB, auditoria.
Reduzir os efeitos dos incidentes, bandeiras finas, quotas, shedding.
Auditoria de configurações: todas as promoções via Git, detecção drive e registro de aplicações.
Políticas de execução: limites/temporizações/retais - como código, com coerção.

16) Resultado

Os ciclos de lançamento são um ritmo controlado entre velocidade e confiabilidade. Slots fixos onde você precisa de coordenação; «a pedido» onde a automação é madura. Em todo o lado - um calendário, bandeiras e salões de canário, gardrelas automáticas e comunicações transparentes. Assim, os lançamentos se tornam previsíveis, seguros e econômicos.