8.6 Gestão de lançamentos e entrega progressiva

Visão geral e motivação

A ideia mais útil da gestão moderna de lançamentos é também a mais simples: entregar código e expor uma funcionalidade são dois eventos diferentes, e vocês devem poder fazer um sem o outro. O capítulo 8.1 (CI/CD e entrega) faz a sua mudança ser construída uma vez, testada e promovida como um artefato imutável. Este capítulo trata do que vem a seguir: como transformar esse código implantado numa experiência ao vivo para usuários reais, de forma gradual, segura e com um caminho rápido de volta. Implantação (deployment) significa instalar código em servidores. Lançamento (release) significa deixar os usuários alcançarem uma capacidade. Quando vocês os separam, uma implantação vira rotina e fica enfadonha, e um lançamento vira uma decisão controlada e reversível.

Para grandes equipes, essa separação muda a temperatura emocional de entregar. Quando dezenas de serviços e centenas de engenheiros mudam a produção todos os dias, um modelo acoplado em que “implantar é lançar” faz de toda mudança voltada ao usuário um evento arriscado e de uma só vez. Desacoplar permite mesclar trabalho inacabado atrás de uma chave, liberar uma funcionalidade para um por cento do tráfego, observar os números e ampliar ou recuar sem tocar no build. Entrega progressiva (progressive delivery) é o termo guarda-chuva para isso: lançar uma mudança para uma audiência crescente enquanto verificações automatizadas decidem se continuam.

Os contextos corporativo e governamental acrescentam coordenação e prova. Uma plataforma de pagamentos lança entre muitos serviços que precisam concordar sobre um esquema. Uma agência pública opera sob uma autorização para operar e um controle formal de mudanças, e os auditores querem evidência de exatamente quem foi exposto a quê e quando. Bem feita, a entrega progressiva satisfaz tanto o desejo de andar depressa quanto a obrigação de provar controle, porque o mesmo mecanismo que limita o raio de impacto também produz um registro auditável do lançamento.

Princípios fundamentais

Implantar não é lançar. Entreguem o código às escuras e depois liguem-no deliberadamente.
Raio de impacto pequeno primeiro. Exponham uma mudança a poucos antes de expô-la a todos.
Todo lançamento tem uma marcha à ré. Se vocês não conseguem reverter em segundos, ainda não terminaram de projetar o lançamento.
Deixem os sinais conduzirem a promoção. Métricas de saúde e orçamentos de erro, não calendários nem otimismo, decidem se um lançamento avança.
Uma flag é um passivo até ser removida. Cada chave é código que vocês precisam manter e, por fim, apagar.
Façam a mudança de banco de dados sobreviver nos dois sentidos. Os lançamentos e as reversões precisam ser ambos seguros contra o mesmo esquema.
As aprovações devem registrar, não obstruir. A evidência de auditoria é um subproduto do pipeline, não uma reunião semanal.

Recomendações

Separe a implantação do lançamento com feature flags

Uma feature toggle, ou feature flag, é uma chave em tempo de execução que decide se um caminho de código está ativo, sem reimplantar. Tratem as flags como um vocabulário tipado, porque suas vidas úteis diferem. Uma flag de lançamento esconde trabalho em andamento e vive de dias a semanas. Uma flag operacional (uma chave de emergência, ou kill switch) permite desligar um subsistema sob carga e pode viver indefinidamente. Uma flag de experimento divide o tráfego para um teste controlado e vive pelo tempo do experimento. Uma flag de permissão condiciona uma capacidade por plano ou papel e é, na prática, permanente. Deem a cada flag um dono, um tipo, um padrão e uma data esperada de remoção. O padrão deve ser o seguro, de modo que uma queda do serviço de flags falhe fechada para o comportamento sabidamente bom e não aberta para caminhos não testados.

Escolha um padrão de entrega progressiva por nível de serviço

Ajustem o mecanismo de lançamento ao raio de impacto, como o capítulo 8.1 argumenta para as estratégias de implantação. Um lançamento canário encaminha uma pequena fatia do tráfego para a nova versão e só amplia se a saúde se mantiver. Uma implantação blue-green mantém dois ambientes de produção e desloca o tráfego entre eles para uma virada e uma reversão instantâneas. Uma implantação gradual (rolling) substitui as instâncias em lotes. Uma implantação em anéis (ring-based) se expande por audiências nomeadas: usuários internos primeiro, depois uma coorte beta, depois uma pequena região, depois todos. Os anéis são o enquadramento mais útil para grandes organizações porque nomeiam quem está exposto em cada passo, que é exatamente o que um auditor e quem responde a incidentes querem saber. As plataformas de contêineres e a orquestração (capítulo 8.3) oferecem as primitivas de modelagem de tráfego que tornam esses padrões baratos de rodar.

Condicione os lançamentos a verificações de saúde e reversão automática

Definam critérios objetivos de saúde antes do lançamento, não durante o incidente. A análise automatizada compara o canário com a linha de base em taxa de erro, latência e saturação e promove ou reverte sem esperar que um humano note. Liguem a promoção ao seu objetivo de nível de serviço e ao orçamento de erros da engenharia de confiabilidade de sites (capítulo 9.1): quando o orçamento está saudável, vocês lançam livremente, e quando está gasto o pipeline se recusa a avançar até o serviço se estabilizar. A reversão automática importa mais, porque remove a hesitação que transforma uma pequena regressão numa grande interrupção. A reversão rápida também é o seu controle de incidente mais barato: uma reversão que leva segundos encolhe o raio de impacto antes mesmo de o seu processo de incidente (capítulo 9.3) entrar em plena marcha. A taxa de falha de mudanças e o tempo de recuperação que vocês melhoram assim são os mesmos sinais de fluxo e de estabilidade que o seu pipeline de entrega acompanha (capítulo 11.2).

Use lançamentos às escuras e tráfego-sombra para reduzir o risco

Algumas mudanças são consequentes demais para encontrar usuários reais pela primeira vez em exposição plena. O lançamento às escuras (dark launch) entrega uma funcionalidade desligada e depois a exercita internamente ou contra uma fração da produção antes de alguém vê-la. O tráfego-sombra (shadow traffic) copia requisições ao vivo para o novo caminho de código e descarta as respostas, de modo que vocês medem carga e correção reais com impacto zero para o usuário. Essas técnicas permitem validar uma reescrita ou uma nova dependência sob tráfego autêntico, o que nenhum ambiente de staging reproduz com fidelidade. Combinem-nas com a mesma análise de saúde que usam para os canários.

Rode experimentos controlados pelo mesmo sistema de flags

A flag de experimento é onde a engenharia de lançamentos encontra o aprendizado de produto. Uma divisão de teste A/B serve variantes a coortes comparáveis e mede um resultado escolhido, alimentando a prática de análise de produto do capítulo 7.4. Reutilizem um só sistema de flags e de segmentação tanto para lançamentos de segurança quanto para experimentos, para ter um único rastro de auditoria e uma única chave de emergência e não duas pilhas paralelas de chaves que discordam sobre quem está em qual balde.

Mantenha o banco de dados retrocompatível com expandir e contrair

Os lançamentos e as reversões só permanecem seguros se o esquema tolera código antigo e novo ao mesmo tempo, o que é inevitável durante qualquer lançamento gradual. Usem o padrão de expandir e contrair (expand and contract, ou mudança paralela): primeiro expandam acrescentando novas colunas ou tabelas numa migração retrocompatível, depois implantem código que escreve nas formas antiga e nova, depois preencham o histórico, depois movam as leituras e só muito mais tarde contraiam, removendo a forma antiga quando nenhum código em execução depender dela. Nunca combinem uma migração destrutiva com a implantação que precisa dela. Essa disciplina é o que permite reverter o código sem um banco de dados que já seguiu em frente, e se liga diretamente à sua estratégia de testes (capítulo 2.4), que precisa cobrir a janela de versões mistas.

Faça a gestão de mudanças registrar em vez de obstruir

Reconciliem auditoria e fluxo pré-aprovando classes de mudança. Definam tipos padrão de mudança de baixo risco que fluem automaticamente pelo pipeline, capturando quem aprovou, que testes rodaram, que artefato foi implantado e que audiências foram expostas em cada anel. Reservem a revisão humana de um comitê consultivo para mudanças genuinamente de alto risco. Um tradicional conselho de controle de mudanças que inspeciona toda implantação rotineira vira um gargalo que empurra as equipes a lotes maiores e mais arriscados, o oposto do que pretende. No governo, uma autorização para operar e um controle formal de mudanças podem coexistir com a entrega progressiva quando a ferramenta de lançamento emite a evidência que o framework de controle exige, de modo que o registro por anéis é o artefato de auditoria.

Compromissos: prós e contras

Padrão	Prós	Contras	Melhor ajuste
Canário	Guiado por dados, raio de impacto pequeno	Precisa de boas métricas e volume de tráfego	Grandes serviços voltados ao usuário
Blue-green	Virada e reversão instantâneas	Dobra o custo do ambiente durante a troca	Serviços críticos que precisam de reversão rápida
Gradual (rolling)	Barato, simples, sem ambiente extra	Reversão lenta, versões mistas ao vivo	Serviços internos sem estado
Em anéis	Audiências nomeadas, rastro de auditoria claro	Lançamento completo mais lento. Mais coordenação	Patrimônios regulados e multisserviço
Feature flags	Desacoplam a implantação do lançamento. Chave de emergência instantânea	Dívida de flags. A matriz de testes cresce	Equipes que entregam trabalho incompleto com segurança
Trens de lançamento	Cadência previsível, coordenação fácil	Acopla muitas mudanças. Espera pelo trem	Muitas equipes compartilhando um lançamento
Lançamento sob demanda	Lotes pequenos, retorno rápido	Coordenação entre equipes mais difícil	Equipes de entrega contínua de alta confiança

A tensão central é entre coordenação e independência. Os trens de lançamento agrupam as mudanças de muitas equipes numa agenda fixa, o que é fácil de raciocinar mas força uma mudança pronta a esperar e acopla trabalho não relacionado num só evento. O lançamento sob demanda deixa cada equipe entregar quando estiver pronta, o que é mais rápido mas exige que os serviços permaneçam implantáveis de forma independente e retrocompatíveis. A solução costuma ser desacoplar no nível do artefato e do esquema para que as equipes possam lançar sob demanda e depois usar flags e anéis para coordenar o momento visível ao usuário em que uma funcionalidade entre serviços de fato liga. Assim o lançamento técnico e o lançamento de produto são decisões separadas, e nenhuma bloqueia a outra.

Perguntas para discutir com sua equipe

Quando um lançamento dá errado às 2 da manhã, quantos segundos leva para reverter, e quem ou o que puxa o gatilho? A resposta honesta revela se vocês realmente separaram a implantação do lançamento ou apenas acrescentaram flags por cima de um processo acoplado. Uma reversão que exige reconstruir, desfazer uma migração de banco de dados ou acionar um humano para decidir não é uma reversão, é um segundo incidente. Levem o mecanismo real dos seus três principais serviços: a flag ou a mudança de tráfego que reverte a exposição, o sinal de saúde que a dispara automaticamente e a garantia de esquema que torna a reversão segura. Para um grande patrimônio, isso determina o seu raio de impacto real, porque a reversão rápida e automática é o que impede uma regressão de virar interrupção. Se a resposta se mede em reuniões e não em segundos, isso é a primeira coisa a consertar.
Qual é a sua política para aposentar flags, e quanta dívida de flags vocês carregam agora? Toda feature flag é uma bifurcação no seu código que multiplica o número de estados que vocês precisam raciocinar e testar, e uma flag que sobrevive ao seu propósito é puro passivo. Decidam a regra agora: toda flag de lançamento recebe um dono e uma data de expiração, as flags obsoletas aparecem num painel e removê-las é trabalho planejado e não uma limpeza para um dia. Levem a contagem de flags ativas, suas idades e quantas passaram da data prevista de remoção. Numa base de código grande, as flags descontroladas viram complexidade condicional permanente que ninguém ousa apagar, e o mecanismo de segurança vira fonte de bugs. A tolerância da equipe a esse número é na verdade uma declaração de quão a sério ela leva a higiene operacional.
O seu processo de aprovação de mudanças torna os lançamentos mais seguros, ou apenas mais lentos? Muitas organizações mantêm um comitê consultivo de mudanças que revisa toda implantação, e a pergunta incômoda é se ele alguma vez de fato impediu uma mudança ruim ou apenas acrescentou latência. Levem dados: o atraso mediano de aprovação, a taxa de falha de mudanças para as revisadas pelo comitê versus as pré-aprovadas e com que frequência a revisão agrupa mudanças pequenas em maiores e mais arriscadas. O objetivo é reservar a revisão humana para mudanças genuinamente de alto risco enquanto as mudanças padrão fluem pelo pipeline com captura automática de evidências. Em contextos regulados e governamentais, verifiquem que a ferramenta de lançamento produz o registro de auditoria que o framework de controle precisa, para que o controle seja um subproduto de entregar e não um portão na frente. Se a revisão acrescenta atraso sem reduzir falhas, é teatro vestido de conformidade.
Em que sinais objetivos de saúde vocês aceitam deixar uma máquina agir, e todo serviço de nível superior de fato tem métricas boas o bastante para condicionar? A análise canário automatizada e o condicionamento por orçamento de erros só funcionam se a taxa de erro, a latência e a saturação forem medidas com limpeza suficiente para confiar numa promoção ou reversão sem humano no circuito, e muitas equipes descobrem durante um incidente que os seus sinais são ruidosos ou esparsos demais para decidir. Para um grande patrimônio, isso determina quanto do seu volume de lançamentos pode fluir com segurança sem vigilância manual, que é a diferença entre uma plataforma que escala e uma que precisa de uma pessoa observando cada lançamento. Levem os painéis reais dos seus três serviços mais críticos: as métricas em que vocês condicionam, o volume de tráfego que torna um canário estatisticamente significativo e a taxa de falsos positivos da sua análise automatizada. Em contextos regulados e governamentais, os mesmos sinais alimentam o registro auditável, então a observabilidade fraca é ao mesmo tempo uma lacuna de confiabilidade e de conformidade, e financiar a qualidade das métricas deve ser uma linha nomeada no plano e não uma capacidade presumida.
As suas mudanças de esquema de fato sobrevivem a uma reversão, e como vocês provam que a janela de versões mistas é segura antes de entregar? A entrega progressiva promete uma marcha à ré rápida, mas uma migração destrutiva acoplada a uma funcionalidade anula essa promessa em silêncio, porque reverter o código o deixa apontado para um banco de dados que já seguiu em frente. Para uma grande organização em que muitos serviços compartilham um esquema, o risco se compõe: o passo de contração de uma equipe pode encalhar a reversão de outra, então a disciplina de expandir e contrair precisa ser um padrão compartilhado e não um hábito local. Levem o seu manual de migrações e a evidência de que é seguido: como separam o expandir do contrair, se a escrita dupla e o preenchimento são testados sob carga e como a suíte de testes exercita o código antigo contra o esquema novo e o código novo contra o antigo. Para patrimônios corporativos e governamentais que carregam dados de vida longa e controle formal de mudanças, uma migração irreversível não é só um risco de interrupção, é uma exposição de integridade de dados e de auditoria que uma janela de manutenção agendada não vai resgatar.
Quando uma funcionalidade entre serviços atravessa equipes que entregam em velocidades diferentes, quem é dono do momento em que ela liga, e como vocês coordenam sem acoplar as implantações? O ponto inteiro de separar a implantação do lançamento é que cada equipe possa entregar o seu artefato de forma independente enquanto uma única flag controla o lançamento visível ao usuário, mas isso só vale se alguém for dono da decisão de lançamento e da segmentação da flag entre as fronteiras de serviço. Para uma grande equipe, o modo de falha é um trem de lançamento de fato que ninguém escolheu: um serviço lento força todas as outras equipes a esperar, ou uma virada de flag descoordenada expõe uma funcionalidade pela metade. Levem o mapa de dependências do seu próximo lançamento multisserviço, o dono da flag de lançamento e as garantias de retrocompatibilidade que deixam cada serviço implantar no próprio relógio. Em programas corporativos e governamentais com aprovações formais de lançamento, nomeiem quem aprova a ativação entre serviços e que evidência essa pessoa vê, para que o lançamento coordenado seja uma decisão deliberada e registrada e não um acidente de quem fez o merge por último.

Perspectiva por setor

Startup. Separar a implantação do lançamento vale a pena mesmo com três engenheiros, mas mantenham barato. Envolvam o trabalho novo numa flag de lançamento com padrão desligado, entreguem no trunk e liguem as funcionalidades primeiro para vocês mesmos antes dos clientes, de modo que uma mudança inacabada nunca bloqueie uma implantação. Pulem as plataformas pesadas de análise canário que vocês não conseguem manter com equipe: um serviço hospedado de flags e uma chave de emergência firme compram a maior parte da segurança, e uma pessoa dona de um ritual semanal de limpeza de flags impede que a dívida engula a sua velocidade.

Pequena empresa. Sem engenheiro de lançamentos e com orçamento apertado, apoiem-se em qualquer entrega progressiva que a sua plataforma existente já ofereça, em vez de construir um sistema de lançamento. A hospedagem gerenciada, um SaaS de feature flags ou o lançamento em estágios embutido no seu framework costuma cobrir o pequeno raio de impacto de que vocês precisam. Tratem a marcha à ré como o que vocês precisam acertar: uma mudança que se desliga em segundos importa muito mais que uma análise automatizada sofisticada que vocês não têm tempo de ajustar.

Grande empresa. O problema é a consistência entre muitas equipes e serviços: um vocabulário compartilhado de flags com donos, tipos e expiração, lançamento padrão em anéis e condicionamento por orçamento de erros aplicado do mesmo modo em toda parte, para que os grupos parem de inventar pilhas rivais de chaves. Governem a dívida de flags como uma métrica de todo o patrimônio, padronizem as migrações de expandir e contrair para que a mudança de esquema de uma equipe nunca encalhe a reversão de outra e façam do registro auditável do lançamento um subproduto que todo serviço emite no mesmo formato. Pré-aprovem as mudanças padrão e reservem a revisão humana para as genuinamente de alto risco, para que o controle escale sem um conselho no caminho crítico.

Governo. As regras de contratação, a transparência e a prestação de contas públicas moldam todo lançamento. Façam da ferramenta de lançamento a fonte da evidência de auditoria, de modo que cada expansão de anel registre a autoridade aprovadora, os testes que rodaram, o hash do artefato e a população exata exposta, e uma autorização para operar coexista com a entrega progressiva em vez de brigar com ela. Prefiram padrões blue-green ou em anéis cujas audiências nomeadas um auditor e quem responde a incidentes consigam ler, validem as mudanças consequentes com tráfego-sombra contra casos reais antes que qualquer cidadão seja afetado e mantenham o registro auditável como o artefato que o framework de controle aceita no lugar de uma janela agendada de big-bang.

Exemplos

Startup. Uma empresa de SaaS de dez pessoas entrega no trunk muitas vezes por dia e envolve toda nova capacidade numa flag de lançamento com padrão desligado. Uma nova integração de cobrança arriscada é lançada às escuras: rodam tráfego-sombra contra ela por uma semana, observando-a tratar formatos reais de requisição sem impacto sobre clientes, e depois a liberam anel por anel, começando pelas próprias contas e por um punhado de clientes beta amigáveis. Quando as taxas de erro disparam no anel de cinco por cento, uma verificação automatizada desliga a flag em segundos, e eles depuram com calma na segunda-feira. Um engenheiro é dono de um ritual semanal de limpeza de flags para que as chaves nunca se acumulem.

Grande empresa. Uma empresa global de pagamentos coordena uma mudança que atravessa seis serviços e um esquema compartilhado. Cada equipe implanta seu artefato de forma independente e retrocompatível usando expandir e contrair, de modo que as novas colunas existam e recebam escrita dupla muito antes de qualquer usuário ver a funcionalidade. O lançamento visível ao usuário é uma única flag de experimento, liberada por anéis atrelados à saúde do orçamento de erros: interno, depois um pequeno país, depois uma porcentagem crescente, com análise canário automatizada promovendo ou revertendo a cada passo. Um serviço de governança de flags impõe donos, tipos e expiração em todo o patrimônio, e as mudanças padrão pré-aprovadas fluem sem um conselho, enquanto apenas o passo de contrato de esquema recebe revisão humana. Cada transição de anel é registrada, então o rastro de auditoria se escreve sozinho.

Governo. Uma agência nacional de benefícios opera sob uma autorização para operar e um controle formal de mudanças. Em vez de tratar a entrega progressiva como um risco de conformidade, ela faz da ferramenta de lançamento a fonte da evidência de auditoria: cada expansão de anel registra a autoridade aprovadora, os testes que rodaram, o hash do artefato e a população exata exposta. Um novo cálculo de elegibilidade é lançado às escuras e validado com tráfego-sombra contra casos reais, depois liberado região por região atrás de uma flag, com virada blue-green para reversão instantânea. As mudanças padrão são pré-classificadas para que o trabalho rotineiro não enfileire atrás de um conselho, enquanto as mudanças de política de alto risco ainda recebem revisão formal. O registro auditável do lançamento satisfaz o framework de controle de modo mais completo do que o antigo lançamento trimestral de big-bang jamais satisfez.

Justificativa de negócio: motivações, ROI e TCO

O retorno da entrega progressiva é dominado pelos incidentes evitados e pela severidade reduzida. Uma mudança que atinge um por cento dos usuários e reverte sozinha custa um erro de arredondamento, onde o mesmo defeito em exposição plena pode significar horas de interrupção, resposta de emergência e dano à reputação. Desacoplar a implantação do lançamento também converte o lançamento em si, de um evento agendado e de alto estresse, num evento de rotina, o que reduz o imposto de coordenação que cresce de forma não linear com o tamanho da equipe. Separar a decisão de lançamento da implantação deixa produto e engenharia andarem em seus próprios relógios, de modo que uma data de marketing nunca force um congelamento arriscado de código.

O custo total de propriedade é real mas modesto diante desse ganho. Vocês investem numa plataforma de flags, em ferramentas de análise canário, em métricas de saúde boas o bastante para condicionar e na disciplina de mudanças de esquema retrocompatíveis. O custo recorrente é a higiene de flags e a matriz de testes maior que as flags criam, e é por isso que um patrimônio de flags não gerenciado é o principal jeito de essa prática ficar cara. O custo de não adotar é pago em raio de impacto: todo lançamento é tudo ou nada, as reversões são lentas e uma única implantação ruim pode derrubar todo mundo de uma vez. Para organizações reguladas, o dividendo de conformidade é decisivo, porque o mesmo mecanismo que limita a exposição também gera a evidência auditável que de outro modo seria montada à mão.

Antipadrões e armadilhas

Implantar é igual a lançar. Acoplar os dois faz de toda mudança voltada ao usuário um evento arriscado, de uma só vez e sem marcha à ré.
Dívida de flags. As chaves que sobrevivem ao seu propósito viram complexidade condicional permanente que ninguém ousa apagar.
Flags que falham abertas. Uma queda do serviço de flags que assume o padrão do caminho novo e não testado transforma um pequeno soluço numa interrupção.
Reversão que precisa de um desfazer de esquema. Uma migração destrutiva entregue com a sua funcionalidade deixa vocês incapazes de reverter o código com segurança.
Promoção manual por intuição. Avançar um lançamento porque “parece bem” em vez de por critérios definidos de saúde e orçamentos de erro.
Lançamento sem plano de reversão. Projetar como ligar uma funcionalidade sem projetar como desligá-la.
Carimbo de conselho de mudanças. Uma revisão que nunca rejeita nada acrescenta atraso sem acrescentar segurança e empurra as equipes a lotes grandes.
Flags de experimento e de segurança em sistemas separados. Duas pilhas de chaves que discordam sobre quem está em qual balde, dobrando a superfície de auditoria.

Modelo de maturidade

Nível 1, Iniciar: A implantação e o lançamento são o mesmo evento. As mudanças saem todas de uma vez, reverter significa reimplantar um build antigo à mão e as migrações de esquema são destrutivas e acopladas às funcionalidades. Qualquer exposição gradual é ad hoc, reativa e sem documentação.
Nível 2, Desenvolver: As feature flags existem para algumas equipes e escondem trabalho inacabado, mas faltam donos, tipos e expiração, e a dívida se acumula. O canário ou o blue-green é usado em alguns serviços críticos, aplicado de forma inconsistente equipe por equipe. A reversão é roteirizada mas disparada por humano, e as mudanças de esquema só às vezes são retrocompatíveis.
Nível 3, Padronizar: A implantação e o lançamento são separados por padrão em toda a organização. As flags são tipadas, têm dono e expiram, com padrões seguros, seguindo um padrão documentado e imposto. A entrega progressiva com lançamento em anéis e análise canário automatizada é a norma, as migrações de expandir e contrair são exigidas e as mudanças padrão fluem pelo pipeline com captura automática de evidências.
Nível 4, Gerenciar: O processo de lançamento é medido e controlado com dados. A taxa de falha de mudanças, o tempo médio de restauração, a latência de reversão, a idade e a contagem de flags e a taxa de falsos positivos do canário são acompanhados contra linhas de base e orçamentos de erro, e os lançamentos são condicionados a esses SLOs (capítulo 9.1), de modo que a promoção e a reversão agem automaticamente sobre sinais definidos de saúde. A dívida de flags é relatada como métrica de todo o patrimônio e aposentada numa agenda, e os desvios do padrão de lançamento aparecem num painel e não numa revisão pós-incidente.
Nível 5, Orquestrar: A entrega progressiva é continuamente melhorada e integrada em toda a organização. Os lançamentos às escuras e o tráfego-sombra reduzem rotineiramente o risco das grandes mudanças, os experimentos e os lançamentos de segurança compartilham um sistema de flags e um rastro de auditoria, e a política de lançamento se adapta ao estado do orçamento de erros em tempo real. O registro auditável do lançamento satisfaz o controle de mudanças (capítulo 9.3) como subproduto, e a organização ajusta seus anéis, portões e limiares a partir de evidências conforme o patrimônio e o quadro de risco mudam.

Ideias para discussão

Para o seu serviço mais crítico, onde fica a fronteira certa entre uma reversão automática condicionada à saúde e uma decisão humana, e em que sinal vocês confiariam o bastante para deixar a máquina agir sozinha?
Flags de experimento e de lançamento devem compartilhar uma plataforma e uma chave de emergência, ou combiná-las cria mais risco do que remove?
Como vocês decidem entre um trem de lançamento e um lançamento sob demanda quando uma funcionalidade atravessa várias equipes que entregam em velocidades diferentes?
Qual é a meia-vida honesta de uma flag de lançamento na sua base de código, e o que tornaria a remoção tão rotineira quanto a criação?
Como o estado do orçamento de erros deveria mudar quem pode lançar, e quem é dono da decisão de congelar lançamentos quando o orçamento está gasto?
No seu contexto regulado, que evidência específica um lançamento precisa emitir para o framework de controle aceitar a entrega progressiva em vez de uma janela de lançamento agendada?

Principais conclusões

Separem a implantação do lançamento. Entregar código e expor uma funcionalidade são decisões diferentes, e as flags é que as desacoplam.
Lancem de forma progressiva. Os padrões canário, blue-green, gradual e em anéis limitam o raio de impacto. Escolham por nível de serviço conforme o risco.
Condicionem à saúde e aos orçamentos de erro. Deixem sinais definidos e SLOs (capítulo 9.1) conduzirem a promoção e a reversão automáticas, não calendários nem otimismo.
Projetem primeiro a marcha à ré. Uma reversão rápida e segura encolhe o raio de impacto antes de o seu processo de incidente (capítulo 9.3) entrar em plena marcha.
Tipem, atribuam dono e façam expirar toda flag. As flags de lançamento, operacionais, de experimento e de permissão têm vidas úteis diferentes. As flags não gerenciadas viram dívida.
Tornem as mudanças de esquema retrocompatíveis. Usem expandir e contrair para que o lançamento e a reversão permaneçam seguros na janela de versões mistas (capítulo 2.4).
Deixem as aprovações registrarem, não obstruírem. Pré-aprovem as mudanças padrão e reservem a revisão humana para o alto risco, de modo que o registro do lançamento seja a evidência de auditoria.

Referências e leitura complementar

Jez Humble and David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps.
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering.
Pete Hodgson, “Feature Toggles (Feature Flags)” (essay on martinfowler.com).
Danilo Sato, “Canary Release” and Martin Fowler, “BlueGreenDeployment” (essays on martinfowler.com).
Sam Newman, Building Microservices: Designing Fine-Grained Systems (expand-and-contract and independent deployability).
Pramod Sadalage and Scott Ambler, Refactoring Databases: Evolutionary Database Design (parallel-change schema migrations).
Ron Kohavi, Diane Tang, and Ya Xu, Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing.
James Governor, “Progressive Delivery” (RedMonk, the coining of the term).