GitOps e deploy blue-green / sem downtime

Sintoma

Objetivo: implantar alterações de schema e de aplicação sem downtime; chegar perto do zero downtime com migrações expand-contract, ambientes blue-green, feature flags e rollback automático.

1. GitOps: faça do Git a única fonte da verdade

Defina no Git a infraestrutura, as migrações de schema e a versão da aplicação; o deploy é disparado por um merge no repositório (GitOps). Um reconciliador (Argo CD/Flux ou CI/CD) aplica o estado desejado ao ambiente real. Assim cada alteração é auditável, repetível e pode ser revertida para um commit anterior quando necessário.

PostgreSQL

# repo/
#   migrations/  (Vxxx__*.sql)
#   k8s/         (Deployment, Service)
#   flags/       (feature flag config)

2. Altere o schema de forma retrocompatível (expand-contract)

Para zero downtime, não altere o schema em um único passo que quebra compatibilidade; divida em duas fases. EXPAND: adicione a nova estrutura (nova coluna/tabela) de modo que o código antigo e o novo possam rodar ao mesmo tempo (coluna nullable, com default, escrita dupla). DEPOIS que a aplicação passar para a nova estrutura, CONTRACT: remova a coluna/tabela antiga que não é mais usada em uma migração separada. Assim as versões antiga e nova da aplicação rodam lado a lado sem problemas durante o deploy.

PostgreSQL

-- EXPAND (V5): backward-compatible addition
ALTER TABLE customer ADD COLUMN email text;

-- for a while the code writes/reads both columns

-- CONTRACT (V9): drop the old column
ALTER TABLE customer DROP COLUMN mail_old;

3. Coloque comportamentos arriscados atrás de uma feature flag

Execute o novo caminho de código (como ler a nova coluna) condicionalmente atrás de uma feature flag; ative a flag quando o schema estiver pronto e desative-a sem mexer no deploy se algo der errado. Uma flag separa a implantação do código (deploy) da ativação do recurso (release). A fase expand é implantada, mas a mudança de comportamento é ativada de forma controlada e pode ser revertida rapidamente.

PostgreSQL

-- application layer (pseudocode)
-- if flag('new_email_field'):
--     SELECT email FROM customer ...
-- else:
--     SELECT mail_old FROM customer ...

4. Monte o ambiente blue-green

Mantenha dois ambientes idênticos: 'blue' (produção) e 'green' (nova versão). Implante a nova versão da aplicação no green e valide-a antes que receba tráfego real; quando estiver pronta, mude o roteador/tráfego para o green. Ponto-chave: o banco geralmente é COMPARTILHADO, então o schema precisa ser compatível com as duas versões (o expand-contract garante isso). Mesmo que o destino da conexão mude no cutover, a compatibilidade do schema significa zero downtime.

PostgreSQL

# traffic is switched to green (new version)
# shared DB: schema must be compatible with both blue and green

5. Valide o deploy com monitoramento (canary/observação)

Antes de transferir todo o tráfego, monitore métricas como taxa de erros, latência, contagens de erros/locks do banco e lag de replicação; opcionalmente, envie uma pequena porcentagem do tráfego (canary) para o green e observe. Se os indicadores de saúde estiverem bons, aumente o tráfego gradualmente; se estiverem ruins, não prossiga. O monitoramento é a entrada para a decisão de rollback automático.

PostgreSQL

-- live health queries
SELECT count(*) FROM pg_stat_activity WHERE wait_event_type='Lock';
SELECT * FROM pg_stat_replication;

6. Prepare o rollback automático

Se as métricas ultrapassarem o limite, o deploy precisa voltar atrás automaticamente: no blue-green, mude rapidamente o tráfego de volta para o blue (a versão antiga). O rollback da aplicação é instantâneo porque o blue continua rodando. Do lado do schema, o rollback geralmente NÃO É NECESSÁRIO: graças ao expand-contract, o novo schema também é compatível com o código antigo, então reverter a aplicação basta. Por isso as alterações de schema devem ser independentes do deploy da aplicação e sempre retrocompatíveis.

PostgreSQL

# traffic instantly returns to blue (application rollback)
# schema is not rolled back: expand-contract is compatible with old code
# if truly needed: write a new corrective migration