Lançamento progressivo e stajings

(Seção: Arquitetura e Protocolos)

1) Porquê entrega progressiva

O padrão clássico «dave → teste → staging → prod» não garante a segurança: quanto mais perto da produção, maior o risco de inadimplência. O lançamento progressivo minimiza o blast radius, aumentando gradualmente a proporção de tráfego/audiência e reforçando as soluções com métricas e SLO. Na ligação com os stajings, isso dá-nos o downthyme zero, o retrocesso rápido, a repetição do processo e o controle de qualidade mensurável.

2) Termos

Os estagiários são estágios formais do ciclo de vida do artefato: 'dave', 'ci', 'qa/teste', 'staging/pré-prod', 'prod', e ephemeral/preview do ambiente sob os ramais de ficção.
Lançamento progressivo (progressivo delivery) - Inclusão gradual da versão/fic canary, porcentagem rollout, ring-depl, fichiflags, dark-launch, tráfego shadow.
Gates - Critérios automáticos de tolerância (erro rate, p95, métricas de negócios, orçamento de erros SLO).
Promoção do artefato - promoção de um mesmo bilhete assinado entre os stajings (impressable artifact).

3) Mapa e destino dos ambientes

3. 1 Básico

Dave (local/banco de areia): ciclos rápidos, barras de dependência, segurança mínima.
CI (estandes de integração): testes unit/integração/contratual, análise estática, SCA/SAST.
QA/Teste: e2e, carga, regressão. Os dados são sintéticos ou camuflados.
Staging/Pré-prod: A configuração máxima é a mesma, as opções, os limites, o processamento em fundo.
Prod: tráfego de combate, SLO/SLI, alertas, planos de reversão.

3. 2 Adicionais

Ephemeral/Preview per PR: estande automático em pull-request, demolição automática em merge/close.
UAT/Sandbox para equipes de negócios: recepção, demonstrações, cenários de treinamento.
Performance lab: experiências de carga isolada (geradores de tráfego, réplicas de dados).

4) Princípios de estagiários sustentáveis

A configuração como código (IaC, GitOps), a deriva dos ambientes é excluída por código e validações automáticas.
Artefatos Idempotentes, Assinados (SBOM, provenance, attestações), build único → multi-estágio deploy.
Paridade com venda: versões de RAND, limites, políticas de rede, bandeiras incluídas. A diferença é apenas em segredos/dados.
TDM (teste data management): sintética/camuflagem, migração e cidos como parte do pipline.
Observabilidade by design: marcas de lançamento, correlação de logs/traçados, dashboards unificados em todos os estágios.

5) Modelo de lançamento progressivo

5. 1 Ferramentas de aproximação

Ficheflagi: ativação/desativação da função por segmentos (país, cliente, acount, random seed).
Canary: 1-5-10-25-50-100% do tráfego com gates em cada passo.
Ring-deploy: extensão por anéis (internal → imployees → beta → public).
Blue-Green: flip atômica para grandes plataformas de upgrade.
Dark-launch: execução oculta sem impacto sobre o usuário (coleta de métricas).
Shadow-traffic: Espelha as solicitações para uma nova versão sem resposta ao usuário.

5. 2 Gates automáticos

Técnicas: error rate, p95/p99, saturação, queue lag.
Métricas de negócios: autorizações, conversão de pagamento, rejeição de passos de vórtice.
SLO/erro budet: paragem rápida quando o orçamento de erro é queimado de forma acelerada.
Status: tempo mínimo/volume de tráfego por passo para não tomar uma decisão «por ruído».

6) Cadeia típica CI/CD (árbitro)

1. Commit/PR → Build: uma única imagem/pacote, assinatura, SBOM.
2. CI-тесты: unit/integration/contract + security (SAST/SCA/secret-scan).
3. Ephemeral preview: estande automático para verificação manual/UX.
4. QA/Teste: e2e + carga + testes de caos (opcional).
5. Staging: smoke, regressão de caminhos críticos do usuário, verificação de migrações de BD.
6. Prod canary: 1-5% de tráfego → gates → 10-25-50-100%.
7. Retrocesso/conclusão: em caso de problemas - auto-rollback; se for bem-sucedido, será a versão antiga.

7) Gerenciamento de dados e esquemas

Expand-migrate-contract: migrações invertidas, transições de fundo, checkpoint, idempotidade.
Duplicidade de gravações (dual-write) com dedução ou «outbox transacionado».
Masking/pré-seleção de dados para estaging (legal e tecnicamente seguro).
Cash/sessão: armazenamento externo, início quente, política de deficiência flip.

8) Segurança e conformidade

Segredos: KMS/Secret Management, rotation, o princípio dos menores privilégios.
Isolar estagiários: redes/contas/projetos; não permitir a sincronização aleatória com o prod.
Auditoria/Trade de lançamento: quem/o/o/o quando saiu, a versão do artefacto, a mudança de approval.
Fornecimento de software: comprovação de assinatura, política de confiança de registros, proibição de latest.

9) Observabilidade e exploração

Um único formato de rótulos é '<service, versão, commit, estágio, region, ring 03'.
Comparação com baseline: canário vs versão estável em gráficos.
Alertas SLO: alimentos e tecnologia, liminares diferentes para canary.
Post-release monitoramento: no mínimo N horas/dia para efeitos atrasados.

10) Reversões e planos de acidentes

O botão/comando de reversão é parte de um pipline (não craft manual).
A promoção reversa da bandeira é mais rápida do que a deposição (kill-switch).
Contra-medidas de dados: reaproveitamento idumpotente, compensação de transações, dedução.
Playbooks de incidentes: quem decide, canais de comunicação, modelos de mensagens.

11) Custo e desempenho

Os ambientes Ephemeral economizam dinheiro se os carros forem agressivamente removidos.
Blue-Green é duas vezes mais caro durante o lançamento; canary é mais barato, mas requer métricas maduras.
Skeiling automático por carga e janela de lançamento; As quotas de prevaricação.

12) Frequentes anti-pattern

À deriva dos ambientes, redações manuais nos estandes, «é uma coisa pequena».
Um bilhete para o ambiente: rebuild por estágio → «impermeável» prod-bagi.
Testes de dados não atualizados, testes verdes que caem em venda.
Falta de gates - lançamentos de sensações em vez de SLO.
Longo TTL no DNS no Blue-Green; falta de stickiness no tráfego parcial.
Mistura de esquemas de base de dados incompatíveis com canary/stable.

13) Folhas de cheque

Antes da promoção no estaging

• Imagem assinada, SBOM coletado, vulnerabilidades de nível creta encerradas.
• As migrações de BB são reversíveis (expand).
• Os dados dos testes são camuflados/sintéticos.
• Os dashboards/alertas estão prontos para a nova versão.

Antes de entrar em prod

• Plano canary com passos e liminares aprovados.
• Kill-switch e plano de reversão foram testados em estaging.
• Traffic shadow ou dark-launch foram executados (se possível).
• On-call foi notificado e a hora da janela foi concordada.

Após lançamento

• Monitoramento SLO estável N relógio.
• Limpar/migrar «contract» foi aplicado.
• Retrospectiva e update de playbooks.

14) Opções de implementação por arquitetura

Monolito: Estandes de suprimento + Blue-Green, e fici através de bandeiras; canary limitado por URL/cookie.
Microserviços canary/ring são naturais; gerenciamento rigoroso de contratos (CDC), versionização da API.
Serviços Stateful: Blue-Green com um plano de migração aquecido e claro; filas individuais/topics per version.

15) Pipline com GitOps (esboço)

O repositório app (código) libera o artefato → coloca o manifesto no repositório uv.
O agente GitOps (Argo CD/Flux) sincroniza 'eng/dave', 'eng/qa', 'eng/staging', 'eng/prod'.
Promoção - através do pull-request para o catálogo do stage; O Merj vai desencadear a abertura e os gates.

16) Gerenciamento de fichas e plateias

Segmentação por tipo de cliente, país, dispositivo, versão do aplicativo, coorte AB, hora do dia.
Expansão gradual: 1% interna → 5% beta → 25% clientes iniciais → 100% todos.
Experimentos A/B e mulivariedade para hipóteses alimentares no mesmo mecanismo de bandeiras.

17) Cenários práticos

Cenário 1: nova integração de pagamento

1. Ephemeral stand per PR, QA regress. 2) Staging smoke + sandbox provedor.
2. Prod canary 1% pelo cabeçalho 'X-Cohort = internal'. 4) Gates: erro rate pagamento, p95 callback, taxa de transações bem sucedidas.
3. 1→5→25→50→100%; quando a degradação é kill-switch.

Cenário 2: upgrade de rentame (JDK/Node/OS)

Blue-Green em nível de cluster: Green aquecido, migração «expand», flip, observação, flip back em casos de problemas.

Cenário 3: high-risk UI-fish

Dark-launch + fichiflag apenas para usuários beta, coleta X-métricas, expansão gradual do público.

18) Conjunto mínimo de ferramentas

CI: build, testes, assinatura, SBOM.
CD/GitOps: Argo CD/Flux/Spinnaker ou ferramentas de nuvem nativa.
Routing: Ingress/Service Mesh (weighted, header/cookie based).
Ficheflagi: LaunchDarkly/Unleash/Vinha de gravação.
Observabilidade: métricas, logs, traçados, alertas; dashboards para estágio.
TDM, camuflagem, siding, geradores de sintéticos.
Segurança: segredos, KMS, políticas de registros, verificações de dependências.

19) Resumo breve

O lançamento progressivo é uma combinação de inclusão gradual e disciplina rigorosa de estagiários. O sucesso é mantido em quatro pilares: artefatos imutáveis, auto-gates SLO, esquema reversível de dados e reversão rápida. Adicione o ambiente, GitOps e ficheflags e seu lançamento será previsível, seguro e rápido.