Estratégias de implantação e teste de aplicativos

Este documento fornece uma visão geral dos padrões de implantação e teste de aplicativos mais usados. Ele analisa como os padrões funcionam, os benefícios que eles oferecem e o que considerar ao implementá-los.

Suponha que você queira atualizar um aplicativo em execução para uma nova versão. Para garantir um lançamento contínuo, considere o seguinte:

  • Como minimizar o tempo de inatividade do aplicativo, se houver.
  • Como gerenciar e resolver incidentes com o mínimo de impacto nos usuários.
  • Como lidar com implantações com falha de maneira confiável e eficaz.
  • Como minimizar os erros de pessoas e processos para conquistar implantações previsíveis e repetíveis.

O padrão de implantação escolhido depende muito das suas metas de negócios. Por exemplo, talvez seja necessário implementar alterações sem inatividade ou implementar alterações em um ambiente ou subconjunto de usuários antes de disponibilizar um recurso. Cada metodologia discutida neste documento considera as metas específicas que você precisa atingir antes de uma implantação ser considerada bem-sucedida.

Este documento é destinado a administradores de sistemas e engenheiros de DevOps que trabalham na definição e implementação de estratégias de lançamento e implantação para vários aplicativos, sistemas e frameworks.

Estratégias de implantação

Quando você implanta um serviço, ele nem sempre é exposto imediatamente aos usuários. Às vezes, só depois que o serviço é lançado, os usuários veem alterações no aplicativo. No entanto, quando um serviço é lançado no local, a implantação e a liberação ocorrem simultaneamente. Nesse caso, quando você implanta a nova versão, ela começa a aceitar o tráfego de produção. Como alternativa, há estratégias de implantação para provisionar várias versões de serviço em paralelo. Esses padrões de implantação permitem controlar e gerenciar qual versão recebe uma solicitação de entrada. Leia Kubernetes e os desafios da entrega contínua de software para mais informações sobre implantações, versões e conceitos relacionados.

Os padrões de implantação discutidos nesta seção oferecem flexibilidade para automatizar o lançamento de novos softwares. A melhor abordagem depende das suas metas.

Recriar padrão de implantação

Com uma implantação de recriação, você reduz totalmente a versão do aplicativo existente antes de escalonar a nova versão do aplicativo.

O diagrama a seguir mostra como uma implantação de recriação funciona para um aplicativo.

O fluxo de uma implantação de recriação.

A versão 1 representa a versão atual do aplicativo e a versão 2 representa a nova versão do aplicativo. Ao atualizar a versão atual do aplicativo, primeiro diminua as réplicas existentes da versão 1 para zero e, em seguida, implante sequencialmente as réplicas com a nova versão.

Principais vantagens

A vantagem da abordagem de recriação é a simplicidade. Você não precisa gerenciar mais de uma versão do aplicativo em paralelo e, portanto, evita desafios de compatibilidade com versões anteriores dos seus dados e aplicativos.

Considerações

O método de recriação envolve inatividade durante o processo de atualização. A inatividade não é um problema para aplicativos que podem lidar com janelas de manutenção ou interrupções. No entanto, se você tiver aplicativos essenciais com contratos de alto nível de serviço (SLAs) e requisitos de disponibilidade, pode escolher uma estratégia de implantação diferente.

Padrão de implantação de atualização contínua

Em uma implantação de atualização contínua, você atualiza um subconjunto de instâncias de aplicativo em execução em vez de atualizar simultaneamente todas as instâncias de aplicativo, conforme mostrado no diagrama a seguir.

O fluxo de uma implantação de atualização contínua.

Nessa abordagem de implantação, o número de instâncias que você atualiza simultaneamente é chamado de tamanho da janela. No diagrama anterior, a atualização contínua tem um tamanho de janela de 1. Uma instância de aplicativo é atualizada por vez. Se você tiver um cluster grande, poderá aumentar o tamanho da janela.

Com as atualizações contínuas, você tem flexibilidade na forma como atualiza seu aplicativo:

  • É possível escalonar as instâncias do aplicativo com a nova versão antes de reduzir a versão antiga (um processo conhecido como upgrade de pico).
  • É possível especificar o número máximo de instâncias do aplicativo que permanecem indisponíveis enquanto aumenta as instâncias em paralelo.

Principais vantagens

  • Sem inatividade Com base no tamanho da janela, você atualiza gradualmente os destinos de implantação, por exemplo, um por um ou dois por dois. Você direciona o tráfego para os destinos de implantação atualizados somente depois que a nova versão do aplicativo estiver pronta para aceitar o tráfego.
  • Redução do risco de implantação. Quando você implanta uma atualização gradualmente, qualquer instabilidade na nova versão afeta apenas uma parte dos usuários.

Considerações

  • Reversão lenta. Se a nova implantação estiver instável, será possível encerrar as novas réplicas e reimplantar a versão antiga. No entanto, como um lançamento, uma reversão é um processo gradual e incremental.
  • Compatibilidade com versões anteriores. Como o código novo e o código antigo ficam lado a lado, os usuários podem ser roteados para qualquer uma das versões arbitrariamente. Portanto, verifique se a nova implantação é compatível com versões anteriores, ou seja, a nova versão do aplicativo pode ler e processar dados que a versão antiga armazena. Esses dados podem incluir dados armazenados em disco, em um banco de dados ou como parte da sessão do navegador de um usuário.
  • Sessões fixas. Se o aplicativo exigir persistência de sessão, recomendamos que o balanceador de carga seja compatível com permanência e diminuição da conexão. Além disso, recomendamos que você invoque o compartilhamento de sessão quando possível (por meio da replicação de sessão ou do gerenciamento de sessão usando um armazenamento de dados) para que as sessões possam ser separadas dos recursos subjacentes.

Padrão de implantação azul-verde

Em uma implantação azul-verde (também conhecida como implantação vermelha/preta), você executa duas implantações idênticas do aplicativo, conforme mostrado no diagrama a seguir.

O fluxo de uma implantação azul-verde.

No diagrama, azul representa a versão atual do aplicativo e verde representa a nova versão do aplicativo. Apenas uma versão está ativa por vez. O tráfego é roteado para a implantação azul enquanto a implantação verde é criada e testada. Depois de concluir o teste, você encaminha o tráfego para a nova versão.

Depois que a implantação for bem-sucedida, será possível manter a implantação azul para uma possível reversão ou desativá-la. Como alternativa, é possível implantar uma versão mais recente do aplicativo nessas instâncias. Nesse caso, o ambiente atual (azul) serve como a área de preparação para a próxima versão.

Principais vantagens

  • Inatividade zero. A implantação azul-verde permite que a transição ocorra rapidamente sem tempo de inatividade.
  • Reversão de instantâneo. É possível reverter a qualquer momento durante o processo de implantação ajustando o balanceador de carga para direcionar o tráfego de volta ao ambiente azul. O impacto da inatividade é limitado ao tempo que leva para alternar o tráfego para o ambiente azul depois que você detecta um problema.
  • Separação de ambiente. A implantação azul-verde garante que a ativação de um ambiente verde paralelo não afete os recursos compatíveis com o ambiente azul. Essa separação reduz o risco de implantação.

Considerações

  • Custo e despesa operacional. A adoção do padrão de implantação azul-verde pode aumentar a sobrecarga operacional e o custo, porque você precisa manter ambientes duplicados com infraestrutura idêntica.
  • Compatibilidade com versões anteriores. As implantações azul e verde podem compartilhar pontos de dados e armazenamentos de dados. Recomendamos que você verifique se as duas versões do aplicativo podem usar o esquema do armazenamento de dados e o formato dos registros. Essa compatibilidade com versões anteriores é necessária se você quiser alternar facilmente entre as duas versões se precisar reverter.
  • Transição. Se você planeja desativar a versão atual, recomendamos que permita a diminuição adequada da conexão em transações e sessões existentes. Esta etapa permite que as solicitações processadas pela implantação atual sejam concluídas ou encerradas normalmente.

Teste de estratégias

Os padrões de teste discutidos nesta seção normalmente são usados para validar a confiabilidade e a estabilidade de um serviço durante um período razoável sob um nível realista de simultaneidade e carga.

Padrão de teste canário

No teste canário, você lança parcialmente uma alteração e, em seguida, avalia o desempenho dela em relação a uma implantação de referência, como mostra o diagrama a seguir.

A configuração de um teste canário.

Nesse padrão de teste, você implanta uma nova versão do aplicativo junto com a versão de produção. Em seguida, divida e direcione uma porcentagem do tráfego da versão de produção para a versão canário e avalie o desempenho do canário.

Você seleciona as principais métricas para a avaliação ao configurar o canário. Recomendamos que você compare o canário com um valor de referência equivalente e não com o ambiente de produção ativo.

Para reduzir fatores que podem afetar sua análise (como armazenamento em cache, conexões de longa duração e objetos hash), recomendamos que você siga as etapas a seguir para a versão de referência do aplicativo:

  • Verifique se as versões de referência e de produção do seu aplicativo são idênticas.
  • Implante a versão de referência ao mesmo tempo que você implanta o canário.
  • Verifique se a implantação de referência (como o número de instâncias de aplicativos e políticas de escalonamento automático) corresponde à implantação canário.
  • Use a versão de referência para exibir o mesmo tráfego do canário.

Em testes canários, o lançamento parcial pode seguir várias estratégias de particionamento. Por exemplo, se o aplicativo tiver usuários distribuídos geograficamente, será possível lançar a nova versão para uma região ou um local específico primeiro. Para mais informações, consulte Como automatizar análises de teste canário no GKE com o Spinnaker.

Principais benefícios

  • Capacidade de testar o tráfego de produção em tempo real. Em vez de testar um aplicativo usando tráfego simulado em um ambiente de teste, é possível executar testes canários no tráfego de produção em tempo real. Com os lançamentos canários, é necessário decidir em quais incrementos você lançará o novo aplicativo e quando acionará a próxima etapa em uma versão. O canário precisa de tráfego suficiente para que o monitoramento possa detectar claramente qualquer problema.
  • Reversão rápida. É possível reverter rapidamente o tráfego do usuário para a versão mais antiga do aplicativo.
  • Inatividade zero. As versões canário permitem rotear o tráfego de produção ao vivo para diferentes versões do aplicativo sem qualquer tempo de inatividade.

Considerações

  • Lançamento lento. Cada versão incremental requer monitoramento por um período razoável e, como resultado, pode atrasar a versão geral. Os testes canários geralmente podem levar várias horas.
  • Observabilidade. Um pré-requisito para implementar testes canários é a capacidade de observar e monitorar com eficiência a infraestrutura e a pilha de aplicativos. A implementação de um monitoramento robusto pode exigir um esforço significativo.
  • Compatibilidade com versões anteriores e sessões fixas. Assim como nas atualizações contínuas, o teste canário pode representar riscos de incompatibilidade com versões anteriores e persistência de sessão porque várias versões do aplicativo são executadas no ambiente enquanto o canário é implantado.

Padrão de teste A/B

Com o teste A/B, você testa uma hipótese usando implementações de variantes. O teste A/B é usado para tomar decisões de negócios (não apenas previsões) com base nos resultados derivados dos dados.

Ao realizar um teste A/B, você encaminha um subconjunto de usuários para uma nova funcionalidade com base em regras de roteamento, como mostra o diagrama a seguir.

A configuração de um teste A/B.

As regras de roteamento geralmente incluem fatores como versão do navegador, user agent, geolocalização e sistema operacional. Depois de medir e comparar as versões, você atualiza o ambiente de produção com a versão que gerou melhores resultados.

Principais vantagens

O teste A/B é usado melhor para medir a eficácia da funcionalidade em um aplicativo. Os casos de uso dos padrões de implantação discutidos anteriormente se concentram no lançamento de um novo software com segurança e reversão previsível. Nos testes A/B, você controla seu público-alvo para os novos recursos e monitora as diferenças estatisticamente significativas no comportamento do usuário.

Considerações

  • Configuração complexa. Os testes A/B precisam de uma amostra representativa que possa ser usada para fornecer provas de que uma versão é melhor do que a outra. Você precisa pré-calcular o tamanho da amostra (por exemplo, usando uma calculadora de tamanho de amostra de teste A/B) e executar os testes por um período razoável de pelo menos 95%.
  • Validade dos resultados. Vários fatores podem distorcer os resultados do teste, incluindo falsos positivos, amostragem polarizada ou fatores externos (como sazonalidade ou promoções de marketing).
  • Observabilidade. Quando você executa vários testes A/B em tráfego sobreposto, os processos de monitoramento e solução de problemas podem ser difíceis. Por exemplo, se você testar a página de produto A versus a página de produto B ou a página de finalização de compra C versus a página de finalização de compra D, o rastreamento distribuído será importante para determinar métricas como a divisão de tráfego entre as versões.

Padrão de teste de sombra

As técnicas de experimento sequencial, como o teste canário, podem expor os clientes a uma versão inferior do aplicativo durante os estágios iniciais do teste. É possível gerenciar esse risco usando técnicas opcionais como simulação. No entanto, as técnicas de validação não validam as melhorias do aplicativo porque não há interação do usuário com as novas versões.

Com o teste de sombra, você implanta e executa uma nova versão junto com a versão atual, mas de modo que a nova versão fique oculta para os usuários, como mostra o diagrama a seguir.

A configuração de um teste de sombra.

Uma solicitação recebida é espelhada e repetida em um ambiente de teste. Esse processo pode acontecer em tempo real ou de modo assíncrono depois de uma cópia do tráfego de produção capturado anteriormente ser repetida no serviço recém-implantado.

Você precisa garantir que os testes de sombra não acionem efeitos secundários que possam alterar o ambiente de produção existente ou o estado do usuário.

Principais vantagens

  • Impacto zero na produção. Como o tráfego é duplicado, os bugs nos serviços que estão processando dados de sombra não afetam a produção.
  • Como testar novos recursos de back-end usando a carga de produção. Quando usado com ferramentas como o Diffy, o sombreamento de tráfego permite medir o comportamento do serviço em relação ao tráfego de produção em tempo real. Esse recurso permite testar erros, exceções, desempenho e paridade de resultados entre as versões do aplicativo.
  • Redução do risco de implantação. O sombreamento de tráfego geralmente é combinado com outras abordagens, como testes canários. Depois de testar um novo recurso usando sombreamento de tráfego, você testa a experiência do usuário liberando gradualmente o recurso para um número cada vez maior de usuários. Nenhum lançamento completo ocorre até que o aplicativo atenda aos requisitos de estabilidade e desempenho.

Considerações

  • Efeitos colaterais. Com o sombreamento de tráfego, você precisa ter cuidado ao lidar com serviços que modificam o estado ou interagem com serviços de terceiros. Por exemplo, se você quiser testar o serviço de pagamento de uma plataforma de carrinho de compras, os clientes poderão pagar duas vezes pelo pedido. Para evitar testes de sombra que possam resultar em mutações indesejadas ou outras interações propensas a riscos, recomendamos o uso de stubs ou ferramentas de virtualização, como o Hoverfly, em vez de sistemas ou armazenamentos de dados de terceiros.
  • Custo e despesa operacional. O teste de sombra é bastante complexo de configurar. Além disso, como implantações azul-verde, implantações de sombra têm implicações operacionais e de custo porque a configuração requer a execução e o gerenciamento de dois ambientes em paralelo.

Como escolher a estratégia certa

É possível implantar e lançar seu aplicativo de várias maneiras. Cada uma tem vantagens e desvantagens. A melhor escolha se resume às necessidades e às restrições da sua empresa. Considere o seguinte:

  • Quais são suas considerações mais importantes? Por exemplo, a inatividade é aceitável? Os custos restringem você? Sua equipe tem as habilidades certas para realizar configurações complexas de lançamento e reversão?
  • Você tem controles de teste rigorosos ou quer testar as novas versões em relação ao tráfego de produção para garantir a estabilidade da versão e limitar qualquer impacto negativo?
  • Quer testar recursos entre um grupo de usuários para verificar determinadas hipóteses de negócios? É possível controlar se os usuários segmentados aceitam a atualização? Por exemplo, as atualizações em dispositivos móveis exigem ação explícita do usuário e podem exigir permissões extras.
  • Os microsserviços no seu ambiente são totalmente autônomos? Ou você tem um híbrido de aplicativos em estilo microsserviço que trabalham com aplicativos tradicionais e difíceis de alterar? Para mais informações, consulte padrões de implantação em ambientes híbridos e de várias nuvens.
  • A nova versão envolve alterações de esquema? Em caso afirmativo, as alterações de esquema são muito complexas para serem separadas das alterações de código?

A tabela a seguir resume as características salientes dos padrões de implantação e teste discutidos anteriormente neste documento. Ao avaliar as vantagens e desvantagens de várias abordagens de implantação e teste, considere suas necessidades de negócios e recursos tecnológicos e, em seguida, selecione a opção que mais beneficia você.

Implantação ou padrão de teste
Inatividade zero Teste de tráfego de produção real Liberar para os usuários com base nas condições Duração da reversão Impacto nos custos de hardware e nuvem
Recriar
A versão 1 é encerrada e a versão 2 é lançada.		 x x x Rápido, mas prejudicial por causa da inatividade Nenhuma configuração adicional é necessária
Atualização gradual
A versão 2 é lançada gradualmente e substitui a versão 1.		 ✓ x x Lenta Pode exigir configuração extra para upgrades
A versão 2 azul-verde
foi lançada junto com a versão 1; o tráfego é alternado para a versão 2 depois de ser testado.		 ✓ x x Instantâneo É necessário manter os ambientes azul e verde simultaneamente
Canário
A versão 2 é lançada para um subconjunto de usuários, seguido por um lançamento completo.		 ✓ ✓ x Rápido Nenhuma configuração adicional é necessária
A/B
A versão 2 é lançada, sob condições específicas, para um subconjunto de usuários.		 ✓ ✓ ✓ Rápida Nenhuma configuração adicional é necessária
Sombra
A versão 2 recebe tráfego real sem afetar as solicitações do usuário.		 ✓ ✓ x Não se aplica Necessidade de manter ambientes paralelos para capturar e reproduzir solicitações de usuários

Práticas recomendadas

Para manter os riscos de implantação e teste no mínimo, as equipes de aplicativos podem seguir várias práticas recomendadas:

  • Compatibilidade com versões anteriores. Ao executar várias versões do aplicativo ao mesmo tempo, verifique se o banco de dados é compatível com todas as versões ativas. Por exemplo, uma nova versão requer uma alteração de esquema no banco de dados (como uma nova coluna). Nesse cenário, você precisa alterar o esquema do banco de dados para que ele seja compatível com a versão anterior. Depois de concluir um lançamento completo, é possível remover o suporte para o esquema antigo, deixando o suporte apenas para a versão mais recente. Uma maneira de conseguir compatibilidade com versões anteriores é separar as alterações de esquema das alterações de código. Para mais informações, consulte alteração paralela e padrões de refatoração de banco de dados.
  • Integração contínua/implantação contínua (CI/CD). A CI garante que o código verificado na ramificação de recursos seja mesclado com o branch principal somente depois que ele passar nas verificações de dependência, nos testes de unidade e integração e no processo de compilação. Portanto, todas as alterações em um aplicativo são testadas antes de serem implantadas. Com o CD, o artefato de código criado por CI é empacotado e está pronto para ser implantado em um ou mais ambientes. Para mais informações, consulte como criar um pipeline de CI/CD com o Google Cloud.
  • Automação. Se você fornecer atualizações de aplicativos continuamente para os usuários, recomendamos criar um processo automatizado que crie, teste e implante o software de maneira confiável. Também recomendamos que suas alterações de código fluam automaticamente por meio de um pipeline de CI/CD que inclua criação de artefatos, teste de unidade, teste funcional e lançamento de produção. Usando ferramentas de automação, como Cloud Build, Cloud Deploy, Spinnaker, e o Jenkins, você pode automatizar os processos de implantação para serem mais eficientes, confiáveis e previsíveis.
  • IaC e GitOps. Se você precisar gerenciar estratégias complicadas de implantação e teste, use as ferramentas Infraestrutura como código (IaC, na sigla em inglês) e GitOps. O uso da IaC com o Terraform e o Config Connector podem ajudar você a usar a linguagem declarativa para definir sua infraestrutura e estratégias. O uso do GitOps com o Config Sync e o Argo CD (links em inglês) ajuda a gerenciar o código com git.
  • Estratégia de reversão. Às vezes, as coisas dão errado. Recomendamos que você crie uma estratégia de reversão para seguir quando o inesperado acontecer. Ter uma estratégia de reversão confiável pode ajudar os administradores e engenheiros de DevOps a gerenciar os riscos. É possível criar uma estratégia de reversão usando uma plataforma compatível com reversões como recurso integrado, como App Engine eCloud Run do Google Analytics. Para atender às suas necessidades de reversão, você também pode usar ferramentas de automação de lançamento, como Cloud Deploy, Spinnaker e Argo Rollouts.
  • Monitoramento pós-implantação. Para monitorar métricas críticas e alertar a equipe responsável quando uma implantação ou um teste falhar, crie um sistema de monitoramento usando o pacote de operações do Google Cloud. Também é possível ativar reversões automatizadas para implantações que falham nas verificações de integridade. Com o Error Reporting, o Cloud Trace e o Cloud Profiler podem ajudar você a encontrar causa de problemas simples e complexos pós-implantação.

A seguir