Processo de aprovação de lançamentos

1) Alvo e área de responsabilidade

O processo de aprovação de lançamentos fornece mudanças previsíveis e seguras na plataforma sem violação de SLO, receita e complacência. Ele abrange todo o caminho, desde pull request até promoção completa em prod e pós-monitorização.

2) Princípios

1. SLO-first: o lançamento só é permitido com SLI verde/sem burn-rate.
2. Pequenos lotes e reversibilidade: canário/progressivo, rápido rollback.
3. Policy-as-Code: gates, SoD, janelas freeze e classes de risco são automaticamente creditados.
4. Uma única fonte de verdade: artefactos/configs/bandeiras - em Git, o ambiente é apresentado por GitOps-reconsilar.
5. Auditoria e provabilidade: revistas WORM, traço de decisão, proprietários claros.
6. Segurança padrão: segredos separados, privilégios mínimos, geo-gates.
7. Comunicações sem surpresas: Modelos preparados para atualizações internas/externas.

3) Papéis e RACI

Release Gerente (RM) é o dono da linha de montagem, calendário, gates. A/R

Service Owner (SO) é o dono do domínio, aceita riscos, prepara artefatos. A/R

SRE/Plataforma - gates SLO, discagem, auto-revezamentos. R

QA Lead é uma estratégia de verificação, resultados de testes. R

Segurança/Compliance - scan, SoD, regulação. C/A

O FAB (Mudança Advisory Board) é uma solução para a classe normal. A

On-call IC/CL - prontidão para incidentes e comunicações. R/C

Stakeholders - Informações. I

4) Classes de alterações e caminhos de concordância

Sala de aula	Exemplos	Caminho de concordância	Prazo
Standard	Seguros, modelos (doces, configs não invasivos)	Auto-gates + pós-notificação	Relógio
Normal	Novos fichas, esquemas de BB com migração, mudanças de routing PSP	Gates + FAB + entrega progressiva	1-3 dias
Emergency	Fixação P1 quente, desligamento de fies perigosos/exportação PII	IC/RM solução + pós-faturamento FAB	Minutos-relógio

Aumento de classe - ao cruzar limites de risco (pagamentos, RG, PII, limites).

5) Linha de lançamento e gates (fluxo de passagem)

Etapa 0. Planejamento e calendário

Freeze-janelas (feriados/jogos), slot-call e CL, disposição de padrões de status.

Etapa 1. PR → Build

Linterners/licenças, SBOM, unit/contracto tests, segredo-scan.

Etapa 2. Integração/Segurança

E2E (provedores virtualizados PSP/KYC), SAST/DAST, dependency review.

Etapa 3. Estaging/Ensaio

Paridade com venda, migração com reversibilidade, ficheflags entre 5% e 25%, folha de cheque «release drill».

Gate A - Qualidade e segurança (obrigatório)

+ todos os testes/scan são verdes

+ circuitos/configs validos, sem «vermelho» SLI estaging

+ SoD/4-eyes para alterações high-risk

Etapa 4. Pré-Prod (Canário)

1% a 5% do tráfego por segmentos (tenant/geo/banco), runtime-validadores, guard.

Gate B - SLO/gate de negócios

+ sem degradação SLO/KRI (latência/erro/pagamento)

+ sem SRM/anomalias nas métricas de experimentação

+ Comms pronto: rascunho de status/parceiros

Etapa 5. Ramp-up → 25% → 100% (região/tenante)

Promoção passo a passo com temporizadores pós-monitorização.

Etapa 6. Monitoramento pós (30-60 min)

Dashboard de lançamento, burn-rate, queixas/tíquetes, auto-encerramento/rollback em violações.

6) Soluções automatizadas (policy-engine)

Regras pseudo:

SLO-гейт: `deny promote if slo_red in {auth_success, bet_settle_p99}`
PII-export: `require dual_control if config. affects == "PII_EXPORT"`
Freeze: `deny deploy if calendar. freeze && not emergency`
Rollback: `auto if auth_success_drop > 10% for 10m in geo=TR`

7) Artefatos de lançamento

Release Manifest (obrigatório): alvo, classe de risco, áreas (tenant/region), bandeiras, migrações, plano de localização, plano de reversão, proprietário, contatos.
Evidence Pack: Resultados de testes/raias, capturas de tela de dashboards de staging, migrações de dry-run.
Comms Kit: modelos de status (interno/externo/associado), ETA/ETR.
Backout Place: Os passos exatos do retrocesso e os critérios em que ele funciona.

Exemplo (botar YAML):

yaml release:
id: "2025. 11. 01-payments-v42"
owner: "Payments SO"
risk_class: "normal"
scope: { tenants: ["brandA","brandB"], regions: ["EU"] }
rollout:
steps:
- { coverage: "5%", duration: "20m" }
- { coverage: "25%", duration: "40m" }
- { coverage: "100%" }
migrations:
- id: "ledger_ddl_0042"
reversible: true flags:
- id: "deposit. flow. v3"
guardrails: ["api_error_rate<1. 5%","latency_p99<2s"]
rollback:
autoIf:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"

8) Lançadores de canais/Blue-Green/Função-Flag

Canary é um default seguro: pequeno alcance, segmentação por GEO/tenant/BIN.
Blue-Green - para alterações pesadas, mudança de rota, reversão rápida.
As bandeiras são para fichas comportamentais: TTL, kill-switch, guardrails, SoD.

9) Gerenciamento de configs e segredos

Configs como dados, esquemas e validadores; Promoção GitOps com detector draft.
Segredos - em KMS/Secret Gerente, acesso JIT, auditoria e camuflagem.

10) Comunicações e status de página

Interna: war-rum/bate-papo, alerta para ele-call, modelos de update.
Externas: publicações apenas via CL, rascunhos pré-elaborados.
Associados (PSP/KYC/estúdios): notificações targeted quando as integrações forem afetadas.
Estado: O lançamento não é um incidente, mas tem uma janela de observação com métricas.

11) Lançamentos de emergência (Emergency)

Desencadeadores: degradação P1, vulnerabilidade, riscos PII/RG.
Caminho: IC + RM → conjunto mínimo de gates (linter/montagem) → canary 1-2% → monitoramento → promoção.
Obrigatório, pós-faturamento da FAB, pós-mortem, D + 5, documentação de compromissos.

12) Auditoria, SoD e conformidade

SoD/4-eyes: alterações no routing PSP, limites de bónus, exportação de dados.
Registro WORM: quem/o/o/o/o/porquê; versões de políticas; diff/bandeiras/configs.
Geo/Private: dados e logs na jurisdição; Não há PII nos artefatos.

13) Observabilidade e pós-controle

SLI (auth-sucess, bet→settle p99), erro-rate, queixas, conversão, filas.
Alerts: burn-rate, SRM, crescimento de 5xx, degradação PSP sobre bancos/GEO.
Relatórios: CFR, MTTR incidentes de lançamento, tempo médio pós-monitoramento, rate auto-rollback.

14) KPI/KRI processo

Lead Time for Mudança (PR→prod), Mudança Failure Rate, MTTR lançamentos de incidentes.
SLO-gates pass rate, Auto-rollback rate, Freeze compliance.
Coverage of Release Drill (ensaio de stage), SoD violations (objetivo: 0).
Comms SLA (disponibilidade de rascunhos, cumprimento de temporizações).

15) Mapa de trânsito de implementação (6-10 semanas)

Ned. 1-2: definir as classes de alterações, gates e artefatos; incluir linteres, SBOM, segredo-scan; calendário de lançamentos e freeze.
Ned. 3-4: GitOps para configs, canary/blue-green, gates SLO, modelos Comms e war-rum.
Ned. 5-6: policy-engine (SoD/4-eyes, risk-rulas), auto-rollback por métricas; dashboard de lançamentos.
Ned. 7-8: ensaios (staging drills), integração com fichiflags/incidente-bote, relatórios KPI/KRI.
Ned. 9-10: auditoria do WORM, ensinamentos de lançamento DR., otimização do CFR, treinamento de papéis (RM/SO/CL/IC).

16) Antipattern

Lançamentos sem reversibilidade e canary → incidentes em massa.
Ignorar os SLO-gates para o deadline.
Configs/bandeiras sem circuitos e TTL → estados «congelados».
Cliques manuais em venda sem Git/auditoria.
Updates públicos sem CL ou modelos.
Segredos no repositório; acessíveis sem JIT ou registro.
FAB como freio sem dados: as soluções devem ser reforçadas com métricas de lançamento.

Resultado

O processo de aprovação de lançamentos é uma estrutura de engenharia e gestão que conecta qualidade, segurança e velocidade: políticas como código, gates SLO, entrega progressiva, comunicações transparentes e auditoria comprovada. Esta abordagem reduz o CFR e o MTTR, protege a receita e a complacência e permite que os comandos produzam valor com frequência e segurança.