Blue-green deployment: a estratégia de DevOps para zero downtime

Quando comecei a trabalhar como engenheiro de MLOps, precisei publicar um pequeno aplicativo com um modelo de ML para classificação de imagens. A primeira implantação correu bem. Mas, quando atualizei o modelo, o caos começou. Primeiro, o Pod que hospedava meu novo modelo não iniciava por causa de diferenças entre meu ambiente de testes e o de produção. Além disso, os clientes ficaram sem conseguir trabalhar porque o Pod com o modelo antigo já tinha sido substituído pelo meu novo Pod que nem iniciava. Um pesadelo. Precisei fazer rollback manual e pedir desculpas aos usuários daquele modelo. 

Aprendi a lição e passei a usar a estratégia de blue-green deployment. Essa abordagem de DevOps permite enviar atualizações sem interrupção e sem rollbacks de madrugada. 

Neste guia, vou mostrar como o blue-green deployment funciona na prática: como configurar, os trade-offs e os aprendizados que você não encontra na documentação. Seja para serviços de ML, APIs ou aplicações full-stack, essa abordagem dá ao seu time a rede de segurança necessária para lançar novas funcionalidades com confiança.

Entendendo o blue-green deployment

Blue-green deployment parece mais complicado do que é (pelo menos para mim, pareceu difícil quando ouvi pela primeira vez). 

É um artifício inteligente para liberar novas versões sem atrapalhar os usuários. Faz isso mantendo dois ambientes de produção idênticos e alternando o tráfego entre eles. 

Se você já passou pela situação de algo funcionar em staging e quebrar em produção, essa é a estratégia certa para você!

Arquitetura central e mecânica operacional

A ideia básica: você mantém dois ambientes de produção idênticos. Um se chama blue e o outro green.

O blue é o ambiente com o qual os usuários interagem no momento. Quando você tem uma nova versão para lançar, faz o deploy no ambiente green, testa e, quando estiver seguro de que está tudo certo, redireciona o tráfego de produção do blue para o green.

Essa estratégia resulta em zero downtime, sem “estamos atualizando”. Só uma transição invisível nos bastidores que os usuários nem percebem.

Na prática, a mágica acontece no load balancer. Você o configura para rotear o tráfego para um dos ambientes, dependendo do status do deploy. Isso dá controle fino sobre o tráfego e torna o rollback tão simples quanto voltar o tráfego para o blue. 

Essa estratégia resolve o momento “mas funcionou no staging”, que eu vivi com meu novo modelo de ML. Como o green também é um ambiente de produção, você testa no mundo real antes de os usuários tocarem nele.

Aqui vai um resumo rápido do fluxo típico: 

1. Fazer o deploy da nova versão no green.
2. Executar testes de integração e smoke tests.
3. Alternar o tráfego via load balancer. 
4. Monitorar o green em busca de anomalias.
5. Se tudo estiver ok, reduzir o blue ou mantê-lo caso seja necessário fazer rollback.

Blue-green deployment – Fase 1: novo aplicativo no green para testes, tráfego ainda roteado para o blue (Imagem do autor).

Blue-green deployment – Fase 2: tráfego redirecionado para o ambiente green (Imagem do autor). 

Evolução histórica e adoção na indústria

A abordagem blue‑green foi batizada e usada na ThoughtWorks por volta de 2005 por Daniel Terhorst‑North e Jez Humble. Depois foi documentada e popularizada no livro Continuous Delivery (2010) de Jez Humble e Dave Farley.

Desde então, é utilizada em todo lugar, de startups a gigantes cloud-native de hoje, como a Netflix e qualquer um que faz deploy várias vezes por dia sem drama.

As plataformas em nuvem aceleraram essa mudança. Com infraestrutura como código, grupos de autoescalonamento e orquestração de contêineres como Kubernetes, criar e manter ambientes duplicados ficou simples.

Blue-green deployment até inspirou outros modelos de deploy, como canary releases e feature flags. Se você entende blue-green, ganha base para entender os demais.

Novo em DevOps? Comece pelo curso DevOps Concepts. Uma base clara e prática para entender as principais estratégias antes de avançar para fluxos mais complexos.

Principais benefícios do blue-green deployment

Sendo bem sincero, quando ouvi falar de blue-green pela primeira vez, achei que não fazia sentido manter dois ambientes de produção. Mas vi como ficou fácil publicar novos modelos de ML e como diminuíram as reclamações e escalonamentos dos usuários. Valia o esforço.

Nos próximos tópicos, vou destacar os benefícios do blue-green deployment.

Downtime quase zero

Esse é o mais óbvio: ninguém quer ficar fora do ar.

Com blue-green, você alterna instantaneamente o tráfego do ambiente antigo para o novo sem degradar o serviço. Seus usuários nem percebem a troca — como deve ser.

É um divisor de águas quando você roda APIs para o usuário final, dashboards ou pipelines de ML que não podem sofrer nem alguns minutos de interrupção.

Rollbacks fáceis

Imagine lançar uma nova versão e, minutos depois, perceber que ela está gerando vários erros internos. Com blue-green, você simplesmente volta o load balancer para o ambiente blue e corrige o problema sem precisar de correria.

Esse nível de segurança dá mais confiança para enviar mudanças com frequência. Adeus ao “em time que está ganhando não se mexe”.

Testes seguros em produção

Você pode testar em produção sem expor os usuários a riscos. Essa é a beleza do ambiente green. Dá para rodar testes de carga, checagens de integração e até simular o comportamento do usuário antes de qualquer tráfego real chegar ao app.

Diferente de ambientes tradicionais de staging, você testa na mesma infraestrutura, configuração e afins.

Isso torna os testes muito mais próximos da realidade.

Suporte a A/B testing e rollouts graduais

Com dois ambientes de produção idênticos rodando, dá para fazer ainda mais. Você pode rotear 90% do tráfego para a versão blue e 10% para a green. 

Também é possível integrar feature flags para controlar quais funcionalidades vão ao ar, quando e para quem, tendo o blue-green como a base de deploy por baixo. 

Se quiser se aprofundar em entrega progressiva, confira CI/CD in Data Engineering. Ele mostra como configurar pipelines que suportam A/B testing e rollouts graduais.

Melhor experiência do usuário e continuidade do negócio

Blue-green deployment ajuda a:

• Expor menos erros aos usuários.
• Aumentar a velocidade de resposta da engenharia quando um problema surge.
• Simplificar a restauração de backups

Se você faz deploy de serviços críticos de machine learning ou ferramentas internas de dados das quais as pessoas dependem todos os dias, isso conta — e muito.

Planejando o blue-green deployment

Antes de implementar blue-green deployment, é essencial entender bem o conceito.

Vamos detalhar o que você vai precisar em termos de arquitetura, custos e prontidão interna.

Requisitos de infraestrutura

Você precisa de dois ambientes de produção idênticos. Isso significa dobrar a configuração e a manutenção.

Mas, antes de se preocupar com o custo, lembre-se: não significa dobrar o custo o tempo todo. Em nuvem ou no Kubernetes, você pode subir recursos para o green só quando necessário e desligá-los depois.

O que ajuda a configurar os dois ambientes:

• Infraestrutura como código (ex.: Terraform) para replicar ambientes rapidamente.
• Gerenciamento de configuração para evitar problemas de drift de configuração.
• No Kubernetes, use namespaces diferentes ou objetos de deployment separados para blue e green.

Também tenha em mente que on‑prem complica mais, pois você precisa garantir:

• Load balancers configuráveis o suficiente para alternar o tráfego instantaneamente.
• Provisionamento rápido de ambientes (talvez via virtualização ou contêineres).
• Dependências externas (bancos, APIs) sincronizadas e isoladas.

Você pode consultar a comparação de serviços AWS, Azure e GCP para decidir o que é mais simples na sua plataforma.

Análise de custo-benefício

Os céticos sempre destacam o aumento de custos de manter dois ambientes de produção. E sim, rodar dois ambientes não é de graça. Porém, existe um equilíbrio entre o custo extra do segundo ambiente e o custo do downtime para o negócio. 

Pergunte a si mesmo:

• Qual é o impacto médio (em tempo ou dinheiro) de um deploy com falha?
• Quantas horas leva para depurar, fazer rollback e explicar a indisponibilidade?
• Com que frequência você publica sob pressão, torcendo para não quebrar?

Esse é o grande argumento do blue-green: menos quedas, iteração mais rápida e menos pressão e burnout na engenharia. 

Dicas para otimizar custos:

• Use autoescalonamento para dimensionar o green conforme a carga de testes.
• Aposte em spot instances ou VMs efêmeras para o green.
• Rode a versão green em um namespace separado no Kubernetes e escale para zero após a virada.

Um pipeline de CI/CD bem configurado pode até automatizar esse escalonamento.

Pré-requisitos e prontidão organizacional

Essa parte costuma ser ignorada, mas é bem essencial.

Mesmo com orçamento para infraestrutura e ferramentas, o blue-green não vai funcionar se a cultura do time e os sistemas não estiverem prontos.

Você vai precisar de: 

• Workflows de CI/CD: pipelines capazes de fazer deploy e testar o green de forma independente.
• Monitoramento e observabilidade: você precisa avaliar as métricas antes de alternar o tráfego do blue para o green.
• Estratégia clara de rollback: idealmente automatizada e, com certeza, praticada.
• Alinhamento multifuncional: Desenvolvimento, Operações, QA e Produto devem entender como o processo funciona.

Se você não tem certeza de como está o seu time, considere CI/CD for Machine Learning. Ele traz uma visão completa de como é um setup de deploy maduro e como chegar lá.

Implementação técnica

Até aqui, vimos por que adotar blue-green deployments. Agora, vou mostrar como implementar. 

Vou detalhar um ciclo típico de blue-green deployment, com foco no desafio de lidar com bancos de dados.

Você vai aprender o que automatizar, o que monitorar e o que não pode deixar passar.

Ciclo padrão de deploy

Um blue-green deployment bem implementado segue uma ordem precisa. Na prática, costuma ser assim:

1. Provisionar o ambiente green: subir um ambiente de nível de produção que espelhe o ambiente atual (blue), seja em nuvem, on‑prem ou em Kubernetes.
2. Fazer o deploy da nova versão no green: seu pipeline de CI/CD deve buildar e publicar o código aqui, idealmente marcando como release candidate atual.
3. Rodar testes automatizados: inclui smoke tests, checagens de integração e probes de saúde que simulam o comportamento do usuário. Você valida se o green está pronto para os usuários.
4. Monitorar logs e métricas: se os dashboards estiverem limpos e sem alertas, siga em frente. Caso contrário, corrija e redeploy no green.
5. Alternar o tráfego para o green: reconfigure o load balancer para rotear todo o tráfego para o servidor green.
6. Desativar o blue: quando tiver confiança no green, desligue o blue ou mantenha como backup até o próximo release.

Deixe o rollback tão rápido quanto o rollout, para que alguém do time reverta um deploy em menos de um minuto.

O guia CI/CD in Data Engineering é um excelente recurso para configurar essas fases automatizadas.

Estratégias de sincronização de banco de dados

Essa parte é complicada. Seu app pode ser stateless, mas o banco não. 

Se você não tratar isso com cuidado, não vai conseguir fazer rollback com facilidade — e aí se perde o objetivo do blue-green deployment.

Veja como lidar:

1. Projete para compatibilidade retroativa: durante a virada, usuários podem atingir o blue por alguns milissegundos. O schema precisa funcionar para ambas as versões nesse período. 
1. Não remova nem renomeie campos imediatamente.
2. Adicione novas colunas/tabelas e use valores padrão.
3. Evite constraints rígidas até as duas versões suportarem a mudança.
2. Versione suas migrações: use ferramentas como Flyway ou Liquibase para Java, ou Alembic para Python + SQLAlchemy. 
3. Trate o estado de sessão: se o app usa sessão em memória, alternar ambientes pode desconectar usuários ou quebrar funcionalidades. Use Redis, Memcached ou um DB compartilhado para evitar isso.
4. Valide a consistência dos dados após a troca: automatize checagens em dados críticos para garantir consistência.
1. Os usuários conseguem fazer login? 
2. As alterações recentes estão sendo salvas? 
3. O pipeline de analytics continua ingerindo corretamente?
5. Monitore desvios sutis: às vezes, mudanças não geram erro visível e parecem funcionar, mas causam problemas sutis, como atrasos no processamento de eventos ou registros malformados. Use logging e observabilidade para detectar cedo.

Se você quer usar MLOps em nível de produção, recomendo o curso MLOps Deployment and Life Cycling.

Análise comparativa com outras estratégias de deploy

Blue-green costuma ser base para outras estratégias de deploy, oferecendo variações para lidar com diferentes pontos do processo. 

Dependendo da sua arquitetura, frequência de releases e apetite por complexidade, considere alternativas — ou até combinar abordagens.

Vamos comparar o cenário mais comum: blue-green vs. canary deployments.

Blue-green vs. canary deployments

Essas estratégias muitas vezes se misturam, mas têm objetivos diferentes.

Blue-green é um modelo de troca completa. Você faz deploy no green, testa e, quando estiver pronto, envia 100% do tráfego para lá.

Canary é uma troca gradual. Você publica a nova versão ao lado da antiga e desloca uma pequena parcela do tráfego (1%, depois 10%, depois 50%) enquanto monitora possíveis problemas.

Principais diferenças entre as duas estratégias:

Eu usei blue-green para publicar modelos de ML em produção, mas a base de usuários era limitada. Se meus modelos fossem expostos a bases maiores, provavelmente preferiria canary releases.

Trade-offs de infraestrutura e operação

Ambas as estratégias exigem boas ferramentas, mas a complexidade aparece em áreas diferentes.

Blue-green precisa de ambientes idênticos, o que aumenta o custo de infraestrutura. Contudo, o roteamento é simples: apenas alternar o tráfego de um ambiente para o outro. 

Já canary é mais leve em custos de infraestrutura, mas exige mais lógica para a mudança gradual de tráfego. Também requer observabilidade mais detalhada para detectar problemas o quanto antes.

Outros fatores a considerar: 

• Monitoramento: canary precisa de métricas granulares (ex.: latência por usuário ou por requisição), enquanto blue-green precisa saber se o app está saudável. 
• Ferramentas de automação: ferramentas como Argo Rollouts suportam ambos os modelos no Kubernetes, mas exigem mais setup para canary.
• Tempo de deploy: blue-green é rápido. Canary é cauteloso e demorado.

Então, o que é melhor para você?

Se seu time ainda está amadurecendo em CI/CD, blue-green pode ser a melhor forma de ganhar confiança. Também é um bom ponto de partida para acumular experiência. 

Mas, se você tem uma grande base de usuários ou publica mudanças de alto risco (como lógica de preços), canary pode ser mais adequado.

Para times focados em Azure, o tutorial de Azure DevOps mostra como implementar um bom CI/CD no Azure.

Implementações específicas por plataforma

Chega de teoria. Vamos para a prática. Veja como o blue-green deployment é implementado nas plataformas que times de dados usam no dia a dia, como Kubernetes, serviços gerenciados em nuvem e ferramentas de automação.

Cada uma oferece recursos diferentes, mas a ideia central é a mesma: dois ambientes idênticos e uma chave de tráfego.

Padrões de orquestração no Kubernetes

Implementar blue-green deployment no Kubernetes é direto, porque as ferramentas necessárias já estão nele. 

Há algumas formas de configurar:

• Deployments separados: publique my-app-blue e my-app-green como deployments distintos, compartilhando labels e services.
• Um único objeto de deployment com revisão: menos comum, mas possível usando anotações para rastrear versões.
• Namespaces: rode blue e green em namespaces separados para isolamento total.

O componente-chave aqui é o Kubernetes Service. Ele atua como load balancer, direcionando tráfego para os pods blue ou green via selectors de label.

Suponha que você tenha:

selector:  version: blue

Depois de validar a versão green, atualize o selector do service para version: green e o tráfego será redirecionado na hora.

Recomendo usar readinessProbes para garantir que a nova versão esteja totalmente pronta antes de rotear qualquer tráfego.

Esse processo pode ser automatizado com ferramentas como Argo Rollouts e Flagger, que cuidam de:

• Mudança progressiva de tráfego
• Health checks e monitoramento
• Rollbacks automáticos se algo falhar

Quer se aprofundar em infraestrutura com foco em ML? Confira Fully Automated MLOps.

Serviços gerenciados cloud-native

Se você está em AWS, Azure ou GCP, a boa notícia é que o blue-green deployment já vem pronto — basta habilitar.

AWS CodeDeploy (com Elastic Beanstalk ou EC2):

• Oferece estratégia dedicada de blue-green deployment
• Você define qual ambiente é o green, e o CodeDeploy cuida da mudança de tráfego e do rollback

Azure Container Apps ou Azure App Service:

• O Azure permite fazer staging de versões como “slots” e trocá-las sem downtime
• Combine isso com pipelines do Azure DevOps para automação completa de CI/CD

Google Cloud (Cloud Run ou GKE):

• O Cloud Run suporta divisão gradual de tráfego entre revisões, perfeito para testes e rollout
• No GKE, use regras de load balancer ou Istio para gerenciar a lógica de blue-green

Cada provedor tem sua configuração e recursos, mas todos facilitam sua vida — você não precisa implementar quase nada do zero. 

Usar serviços gerenciados também traz o benefício de não precisar manter tudo por conta própria: os provedores atualizam seus serviços e você só se preocupa em configurá-los direito.

Novo no GCP? Confira Cloud Run: um guia para publicar apps conteinerizados no GCP.

Exemplo com Cloud Foundry e outras ferramentas

Cloud Foundry é uma plataforma como serviço (PaaS) open source que abstrai a infraestrutura subjacente e permite que desenvolvedores foquem em enviar código. É especialmente popular em grandes empresas por sua automação, recursos de conformidade e fluxos rápidos de deploy.

Veja como um blue-green deployment típico funciona no Cloud Foundry usando a CLI oficial:

1. Faça o push da versão blue do seu app com o subdomínio demo-time:

1. cf create-route example.com --hostname my-appcf push my-appcf map-route my-app example.com --hostname my-app

2. O blue agora está rodando, e o roteador envia todo o tráfego para my-app.example.com.
2. Faça o push da versão green do seu app com um novo nome e rota:

1. cf create-route example.com --hostname my-app-tempcf push my-app-greencf map-route my-app-green example.com --hostname my-app-temp

2. Duas instâncias do aplicativo estão rodando, mas com duas rotas para tráfego (my-app.example.com para blue e my-app-temp.example.com para green).
3. Mapeie a rota de produção para o green:

1. bashcf map-route my-app-green example.com -n my-app

2. Agora, as versões antiga (blue) e nova (green) estão ativas, mas o tráfego é enviado para ambas, a menos que você remova o blue explicitamente.
4. Verifique a versão green funcionando corretamente. Você pode testá-la via sua rota ou monitorar o tráfego real após a troca.
5. Desassocie a rota do blue, migrando totalmente para o green:

1. cf unmap-route my-app example.com -n my-app

2. O roteador não envia mais tráfego para o blue.
6. Exclua o app antigo e a rota do green (opcional, mas recomendado):

cf delete my-appcf unmap-route my-app-green example.com --hostname my-app-temp

Esse processo minimiza downtime e dá controle total sobre quando e como você troca de versão.

Se quiser melhorar esse fluxo com pipelines visuais, aprovações manuais ou rollback automático, ferramentas como Octopus Deploy, Codefresh ou Spinnaker são ótimas opções. Elas se integram bem aos pipelines de CI/CD e permitem automatizar lifecycles complexos de deploy.

Boas práticas e estratégias de otimização

Blue-green deployment é ótimo e ajuda muito, mas pode virar bagunça rápido se você não gerenciar custos, riscos ou automação direito. Já vi times sofrendo com setups complexos demais ou casos de borda inesperados. 

Veja o que fazer para evitar isso e tornar sua estratégia de blue-green um sucesso.

Técnicas de gestão de custos

Duplicar ambientes traz custo extra, claro. 

Mas você pode minimizá-lo com as estratégias abaixo:

• Autoescalonamento: use horizontal pod autoscalers ou autoscaling nativo da nuvem para casar com a carga real e evitar desperdício.
• Instâncias spot e preemptibles: ótimas para o green se você só estiver testando (e aceitar interrupções).
• Provisionamento temporário: não deixe o green ligado mais do que o necessário. Suba via pipeline de CI/CD e derrube depois.
• Containerização: leve, rápida e econômica — especialmente em Kubernetes ou Azure Container Apps.

Frameworks de validação automatizada

Jamais alterne o tráfego sem ter certeza de que seu aplicativo green está funcionando como esperado. 

Use essas camadas de testes para ganhar confiança antes da troca:

• Smoke tests: endpoints chave estão vivos e saudáveis?
• Testes de integração: fluxos centrais (auth, acesso a dados etc.) funcionam no green?
• Testes end-to-end: simule o comportamento real do usuário na rota temporária do green (especialmente útil no Cloud Foundry e Azure).

Integre isso ao seu pipeline de CI/CD para rodar automaticamente após um deploy bem-sucedido.

Precisa relembrar como montar esses fluxos? CI/CD for Machine Learning mostra como estruturar validações automatizadas no ciclo de deploy.

Metodologias de migração de banco de dados

Aqui está o pulo do gato: seu app pode rodar em dois ambientes, mas o banco geralmente é o mesmo para ambos. 

Como fazer uma transição segura:

• Mudanças de schema compatíveis com versões anteriores: sempre assuma que o blue pode continuar usando o banco quando o green entrar no ar.
• Feature toggles: libere funcionalidades dependentes do schema só depois que o novo schema estiver publicado.
• Migrações versionadas: use ferramentas como Flyway, Alembic ou Liquibase para manter mudanças rastreáveis e reversíveis.
• Consistência de sessão/dados: se você depende de estado de sessão, use stores externos (como Redis) compartilhados por ambos os ambientes.

Feature flags e entrega progressiva

Combinar blue-green com feature flags dá ainda mais flexibilidade.

Com flags, você pode:

• Liberar novas features para um subconjunto de usuários dentro do green
• Fazer deploy de features, mas mantê-las ocultas
• Testar com segurança casos de borda ou impactos de performance sem expor o pacote completo

Use ferramentas como LaunchDarkly, ConfigCat ou Unleash para simplificar a gestão sem precisar mudar código.

Monitoramento e observabilidade robustos

Monitoramento e observabilidade são cruciais para alternar tráfego com segurança, pois permitem avaliar se o green está realmente pronto para substituir o blue.

Você deve ter: 

• Health checks: readinessProbes no Kubernetes, URLs de revisão no Azure etc.
• Logging: centralizado, pesquisável e com tags por ambiente (blue vs. green).
• Alertas: defina limites e receba notificações se a taxa de erros subir.
• Análise de tráfego: compare o comportamento entre blue e green (ex.: latência, taxa de erros e throughput).

De todo modo, monitoramento e observabilidade robustos devem fazer parte da sua infraestrutura, com ou sem blue-green.

Planejamento de rollback e recuperação de desastres

Problemas vão acontecer de vez em quando. O objetivo é tornar a recuperação o mais rápida e simples possível. 

Como fazer:

• Rollback instantâneo: mantenha o ambiente blue ativo até verificar que o green está estável.
• Gatilhos automáticos de rollback: use Argo Rollouts ou Spinnaker para reverter o tráfego se métricas-chave falharem.
• Runbooks e playbooks: passos pré-definidos para o time, para que todos saibam o que fazer.

Para mais dicas práticas de automação em DevOps, veja o tutorial de Azure DevOps.

Reforço de segurança

Ter dois ambientes significa também dois pontos potenciais de ataque.

Algumas sugestões para garantir segurança adequada:

• Isole os ambientes: sub-redes, namespaces ou resource groups distintos para garantir isolamento.
• Gire segredos com frequência: especialmente se você usa credenciais compartilhadas entre blue e green.
• Corrija ambos os ambientes: não deixe o green atrasar em updates de segurança só porque ainda não está em produção.
• Audite logs: registre eventos de deploy e trocas de ambiente para rastreabilidade.

Conclusão

Blue-green deployment não é apenas uma estratégia “da moda” que só processos superengenheirados usam. É prática e confiável para times que priorizam disponibilidade, feedback rápido e uma noite de sono tranquila.

Ele oferece:

• Rollbacks instantâneos quando algo dá errado
• Testes em nível de produção sem risco para usuários reais
• Releases mais limpos e confiantes — até às sextas (sem exagero)

Mas é perfeito para todo cenário? Eu diria que não. Você precisa de um setup de CI/CD sólido, com ferramentas que sustentem a jornada. Caso contrário, vira bagunça rápido.

Ainda assim, isso não é motivo para evitar. É, na verdade, um sinal de que você deve evoluir suas práticas de deploy.

Nós melhoramos drasticamente nosso fluxo de releases adotando blue-green deployments e passamos a ter dias de publicação muito mais tranquilos — com confiança até para lançar às sextas.

Se quiser avançar, comece com DevOps Concepts ou MLOps Deployment and Life Cycling, que ajudam a construir a base sobre a qual o blue-green se sustenta.

Agora vá lá e publique seu aplicativo com confiança.