Implantação Blue-Green
Dois ambientes de produção completos, com o tráfego alternado entre eles — permitindo uma reversão instantânea e total caso o novo ambiente apresente problemas.
Implantação e Capacitação · Etapa 05 · Como Trabalhamos
O lançamento é uma decisão, não um evento.
Desenvolvimento & Integração produz software verificado — mas software verificado ainda não é software em produção. Esta etapa define como, quando e com que segurança esse software será exposto ao tráfego real de produção, e garante que as pessoas responsáveis pela operação estejam preparadas antes da sua chegada.
Na OpenQCore, a implantação é tratada como uma exposição controlada ao risco, não como um único momento irreversível. Um lançamento não está "concluído" quando o código chega à produção. Está concluído quando é exposto gradualmente, observado em condições reais e confirmado como seguro — com um caminho definido de retorno caso não o seja.
Não esta pergunta
"O código está pronto para ser lançado?"
Esta pergunta, em vez disso
"Como expomos esta alteração a utilizadores reais de forma a limitar o raio de impacto de qualquer ocorrência não prevista — e conseguimos revertê-la rapidamente, se necessário?"
Entrega progressiva · Contenção de riscos · Reversibilidade · Prontidão · Capacitação
Por que a implantação vem depois da verificação
Verificado não é o mesmo que comprovado em produção.
A etapa anterior confirma que uma mudança atende aos critérios de aceitação nos testes. Não confirma, porém, como essa mudança se comporta sob carga real de produção, com o comportamento real dos utilizadores, ou em interações com sistemas que não podem ser totalmente replicados num ambiente de teste. Implantação & Capacitação existe precisamente porque essa lacuna é real — e porque fechá-la com segurança exige uma disciplina específica.
Pronto para Implantação → Exposição Controlada em Produção
Por que a disciplina de implantação importa
Velocidade sem capacidade de reversão não é progresso.
A mesma pesquisa DORA apresentada em Desenvolvimento & Integração — Accelerate (2018), de Forsgren, Humble e Kim — combina suas métricas de entrega com duas métricas de estabilidade que são relevantes especificamente nesta etapa.
Frequência de Implantação
Com que frequência uma organização faz releases bem-sucedidos em produção.
Forsgren, Humble & Kim, Accelerate (2018); DORA — pesquisa State of DevOps.
Tempo para Restaurar o Serviço
Quanto tempo leva para recuperar quando uma implantação degrada a produção.
Forsgren, Humble & Kim, Accelerate (2018); DORA — pesquisa State of DevOps.
Nesta pesquisa, organizações de alto desempenho não se limitam a implantar com frequência — elas fazem isso de forma a manter o tempo de recuperação curto quando algo dá errado. A OpenQCore vê isso como um único objetivo, não um compromisso: as práticas desta etapa foram desenhadas para tornar as implantações ao mesmo tempo frequentes e rapidamente reversíveis.
Estratégias de Entrega Progressiva
Separe a decisão de liberar para os usuários da decisão de implantar.
As práticas formalizadas em Continuous Delivery (Humble e Farley, 2010) distinguem implantar uma mudança de liberá‑la aos usuários — distinção que a OpenQCore considera uma escolha de projeto fundamental sobre como o software chega à produção.
Releases canários
Uma nova versão é exposta inicialmente a uma pequena fração do tráfego real, monitorada por sinais definidos, e só é ampliada se esses sinais se mantiverem.
Feature Flags
O código pode ser implantado em produção sem estar ativo para os usuários — separando o envio do código da disponibilização de uma funcionalidade.
Ambientes de Implantação e Promoção
Uma mudança conquista seu caminho até a produção. Não é enviada diretamente.
Uma mudança percorre ambientes definidos — desenvolvimento, homologação e produção — com verificações explícitas a cada promoção, e não apenas um único teste seguido de um release direto.
Desenvolvimento
Onde a mudança é construída e inicialmente verificada em isolamento.
Homologação
Onde a mudança é verificada sob condições, configurações e integrações semelhantes às de produção.
Produção
Onde a mudança é exposta ao tráfego real — de forma progressiva e sob observação.
Planejamento de Reversão e Recuperação
O plano de reversão é escrito antes da implantação, não durante o incidente.
Uma estratégia de reversão definida enquanto o sistema já está degradado é decidida sob pressão, com informação incompleta e muitas vezes tarde demais. A OpenQCore define o caminho de reversão de uma mudança antes de sua implantação — não depois que algo dá errado.
Condições Definidas para Acionar a Reversão
Os sinais específicos que acionariam uma reversão, acordados antecipadamente em vez de decididos na hora.
Compatibilidade de Dados e Estado
Consideração explícita sobre se a reversão é segura, dadas as mudanças de dados ou de esquema introduzidas pela implantação.
Objetivo de Tempo de Recuperação
Meta declarada para o tempo em que o serviço deve ser restaurado caso seja necessário um rollback.
Infraestrutura como Código & Reprodutibilidade
Uma implantação que não pode ser reproduzida exatamente não pode ser confiável.
Os passos da implantação são definidos como código — versionados, revisados e executados de forma idêntica todas as vezes — em vez de serem realizados manualmente com base na memória de uma pessoa sobre a sequência correta. Trata‑se de uma prática fundamental no mesmo conjunto de pesquisas sobre entrega contínua mencionado acima: um processo de implantação que não pode ser reproduzido exatamente não pode ser verificado nem automatizado com segurança.
Avaliação de Risco da Implantação
Toda implantação é avaliada antes de ocorrer, não depois.
Em consonância com a modelagem de ameaças introduzida durante Desenvolvimento e Integração, cada implantação é avaliada quanto ao seu perfil de risco específico antes de prosseguir.
Raio de impacto
Quantos usuários, sistemas ou fluxos de trabalho seriam afetados se essa alteração se comportasse de forma inesperada.
Reversibilidade
Com que rapidez e de forma limpa essa alteração pode ser desfeita, caso necessário.
Exposição de Dependências
Quais sistemas ou equipes a jusante são afetados por essa implantação e se já foram informados.
Pipeline de Implantação Progressiva
A exposição só aumenta quando as evidências a justificam.
Canary (pequena porcentagem) → Monitorar sinais definidos → Ampliar exposição → Monitorar sinais definidos → Implantação completa. Em qualquer ponto dessa sequência, um rollback é um resultado planejado — não uma improvisação de emergência. A expansão para a próxima etapa é uma decisão tomada com base nas evidências coletadas na etapa atual, não um comportamento automático que ocorre com o tempo.
Essa abordagem reflete o conceito de orçamento de erros, descrito no Site Reliability Engineering do Google (2016): uma quantidade definida e aceitável de instabilidade que um sistema pode 'gastar', usada para transformar a troca entre velocidade de lançamento e confiabilidade em uma decisão explícita e mensurável, e não em algo implícito.
Preparação: Documentação & Prontidão da Equipe
Um sistema que ninguém consegue operar não foi realmente implantado.
A implantação frequentemente é considerada concluída assim que o software está em produção. O OpenQCore considera que está concluída apenas quando as pessoas responsáveis por operar, suportar e diagnosticar esse software estão realmente preparadas para fazê‑lo.
Runbooks operacionais
Procedimentos documentados para tarefas operacionais comuns, modos de falha conhecidos e como respondê‑los.
Prontidão para plantão
Confirmação de que as pessoas responsáveis por responder a incidentes têm o acesso, o contexto e os caminhos de escalonamento necessários.
Transferência de Conhecimento
Handover explícito do conhecimento operacional para a equipe ou organização que passará a ser responsável pelo sistema.
O Portão de Decisão da Implantação
Uma implantação prossegue porque as evidências a suportam — não porque está agendada.
Toda implantação planejada deve passar por um portão de decisão definido antes de prosseguir.
Implantar
Avaliação de risco, plano de reversão e prontidão atendidos — a implantação prossegue.
Aguardar
Um risco identificado ainda não foi suficientemente mitigado — a implantação aguardará até que ele seja mitigado.
Reversão
Uma alteração implantada acionou uma condição definida de reversão — o estado anterior é restaurado.
Escalar incidente
Uma implantação causou um impacto que exige uma resposta formal a incidentes, além de uma simples reversão.
Um gate de implantação que nunca adia nem reverte não está avaliando riscos — está apenas registrando um cronograma.
O que esta etapa produz
Um sistema em produção e a capacidade de operá‑lo.
Dependendo do escopo de atuação, esta etapa produz:
Runbook de implantação
O procedimento específico e repetível usado para implantar esta mudança e outras semelhantes.
Plano de reversão
As condições de acionamento definidas, o procedimento e o objetivo de tempo de recuperação para reverter esta implantação.
Registro de promoção entre ambientes
Documentação de como a mudança transitou por desenvolvimento, homologação e produção, e o que foi verificado em cada etapa.
Documento de avaliação de risco
O raio de impacto, a reversibilidade e a exposição a dependências avaliados antes da implantação.
Materiais de capacitação da equipe
Runbooks, confirmação de prontidão do plantão e transferência de conhecimento realizadas antes da entrega.
Relatório de implantação progressiva
Os sinais observados em cada etapa de exposição e as evidências que justificam a expansão até a implantação completa.
Da implantação para Monitoramento e Otimização
Em produção não é sinônimo de compreendido.
Implantação e capacitação geram um sistema em produção que opera com segurança e as pessoas responsáveis preparadas para operá‑lo. Ainda assim, não produzem um entendimento contínuo de como esse sistema se comporta ao longo do tempo, nem um mecanismo estruturado para melhorá‑lo. Esse é o propósito da próxima e última etapa desta metodologia.
Exposição controlada em produção → Prontidão operacional → Monitoramento e Otimização
Etapa 06
Monitoramento e Otimização
Compreenda como um sistema em produção realmente se comporta e melhore-o continuamente com base em evidências reais.
Referências de Pesquisa e Metodologia
Forsgren, N., Humble, J., & Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018); Google Cloud, DORA State of DevOps research
Fonte das métricas de frequência de implantação e de tempo de recuperação mencionadas acima.
Humble, J. & Farley, D. — Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (2010)
Fonte da distinção entre deploy e release, das estratégias blue‑green e dos princípios de infraestrutura como código citados acima.
Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (eds.) — Site Reliability Engineering: How Google Runs Production Systems (2016)
Fonte do conceito de 'error budget' citado na seção sobre rollout progressivo acima.