O que são os padrões de implantação?
Um padrão de implantação é uma forma automatizada de distribuir facilmente novos recursos de aplicativos para seus usuários. Um padrão de implantação apropriado ajuda a minimizar o tempo de inatividade. Alguns padrões também permitem distribuir novos recursos progressivamente. Dessa forma, você pode validar novos recursos com os usuários selecionados antes de tornar esses recursos disponíveis para todos.
Nesta seção, você aprenderá sobre alguns padrões de implantação comuns. Você também aprenderá como o Serviço de Aplicativo do Azure ajudará a implementar o padrão escolhido pela equipe da Tailspin.
Reunião matinal
A equipe da Tailspin está se sentindo bem. Seu pipeline acelera seu processo. A equipe tem um ambiente de desenvolvimento no qual pode integrar o aplicativo Web a um banco de dados. Tanto Pedro quanto Marina estão felizes em ter testes automatizados que simplificam seus trabalhos. Em geral, eles veem menos atrasos e menos bugs.
Mas como sempre, há um problema. Vamos entrar na reunião da equipe, em que Pedro está falando.
Pedro: É muito difícil manter todos satisfeitos. Mateus acha que leva muito tempo para lançar novos recursos. Não posso fazer nada até que a gerência aprove a versão e, no momento, não há uma forma tranquila de distribuir os recursos depois que eles derem o OK. Além de longo, o processo é confuso. É manual e há tempo de inatividade. O processo inteiro pode levar cinco dias. Eu sei que isso é muito tempo, mas o que eu deveria fazer? Talvez se eu tomar mais café, a solução virá para mim.
Paulo: Café é essencial para a resolução eficaz de problemas, sem dúvida.
Acho que a solução de que precisamos é um bom padrão de implantação. Um padrão de implantação é uma forma automatizada de fazer a substituição. É assim que passamos o software da fase final de pré-produção para a produção ativa.
Escolher o padrão certo pode, definitivamente, ajudá-lo, por exemplo ao minimizar o tempo de inatividade. Outra vantagem de um padrão de implantação é que ele nos dá a oportunidade de executar testes que deveriam realmente acontecer na produção.
Paulo começa a escrever no quadro de comunicações.
Aqui estão as possibilidades que devemos considerar:
- Implantação "blue-green"
- Versões canário
- Alternâncias de funcionalidades
- Inicializações escuras
- Testes de A/B
- Implantação de exposição progressiva
Vamos discutir brevemente cada padrão.
Implantações azul-verde
Uma implantação azul-verde reduz o risco e o tempo de inatividade executando dois ambientes idênticos. Esses ambientes são chamados de azul e verde. A qualquer momento, somente um dos ambientes está ativo. Uma implantação azul-verde normalmente envolve um roteador ou um balanceador de carga que ajuda a controlar o fluxo de tráfego.
Digamos que o azul esteja ativo. À medida que preparamos uma nova versão, fazemos nossos testes finais no ambiente verde. Depois que o software estiver funcionando no ambiente verde, mudamos o roteador para que todas as solicitações recebidas vão para o ambiente verde.
A implantação azul-verde também nos dá uma forma rápida de fazer uma reversão. Se algo der errado no ambiente verde, basta mudar o roteador de volta para o ambiente azul.
Versões canário
Uma versão canário é uma forma de identificar possíveis problemas cedo, sem expor todos os usuários ao problema. A ideia é expomos um novo recurso a apenas um pequeno subconjunto de usuários antes de disponibilizarmos para todos.
Em uma versão canário, monitoramos o que acontece quando liberamos o recurso. Se a versão tiver problemas, aplicaremos uma correção. Depois que comprovarmos que a versão canário é estável, a moveremos para o ambiente de produção real.
Alternâncias de funcionalidades
Use alternâncias de funcionalidades para "virar uma chave" no runtime. Podemos implantar um novo software sem expor qualquer outra funcionalidade nova ou alterada para nossos usuários.
Nesse padrão de implantação, Clara e eu criamos recursos por trás de uma alternância. Quando ocorre uma versão, o recurso é "desativado" para que ele não afete o software de produção. Dependendo de como configurarmos a alternância, podemos virar a chave para “ativado” e expor o recurso conforme o desejado.
Por exemplo, poderíamos expor o recurso primeiro a um pequeno número de usuários para ver como eles reagem. Essa amostra aleatória de usuários vê o recurso. Ou poderíamos apenas permitir que o recurso fique ativo para todos.
Mas esse padrão de implantação pode beneficiar a Clara e eu mais do que qualquer outra pessoa. A grande vantagem do padrão de alternâncias de funcionalidades é que ele ajuda a evitar a ramificação excessiva. A mesclagem branches pode ser difícil.
Inicializações escuras
Uma inicialização escura é semelhante a uma versão canário ou a mudar uma alternância de funcionalidades. Em vez de expor um novo recurso a todos, em uma inicialização escura, liberamos o recurso para um pequeno conjunto de usuários.
Esses usuários não sabem que estão testando o recurso para nós. Nós nem realçamos o novo recurso para eles. É por isso que ele é chamado de inicialização escura. O software é liberado gradualmente ou de maneira discreta para os usuários, para que possamos receber comentários e testar o desempenho.
Testes de A/B
O teste A/B compara duas versões de uma página da Web ou aplicativo para determinar qual delas tem um desempenho melhor. O teste A/B é como um experimento clássico.
Em testes A/B, mostramos aleatoriamente aos usuários duas ou mais variações de uma página. Em seguida, usamos a análise estatística para decidir qual variação tem o melhor desempenho para nossas metas.
Implantação de exposição progressiva
A implantação de exposição progressiva às vezes é chamada de implantação baseada em anel. É outra maneira de limitar como as alterações afetam os usuários e ainda garantir que elas sejam válidas em um ambiente de produção.
Os anéis são basicamente uma extensão da fase canário. A própria versão canário é lançada em uma fase para medir o efeito. A adição de outro anel é essencialmente a mesma ideia.
Em uma implantação baseada em anel, implantamos as alterações em clientes com tolerância a riscos primeiro. Em seguida, redistribuímos progressivamente para um conjunto maior de clientes.
Implementação da implantação azul-verde
Paulo olha para Pedro.
Paulo: Isso é muito, eu sei. Quer tirar um tempo para pensar nisso? Ou você e eu poderíamos...
Pedro: Azul-verde.
Todos na sala riem.
Clara: Isso é o café falando?
Pedro: As alternâncias de funcionalidades envolvem uma mudança no modo como você e o Paulo trabalham. Vamos fazer uma coisa de cada vez. Os métodos que expõem gradualmente um recurso exigem análise estatística ou alternâncias de funcionalidades.
Uma implantação azul-verde é algo que posso controlar. Mudar um roteador é simples. É fácil e parece seguro. E em uma implantação azul-verde, o gerenciamento tem um ambiente para avaliar. Quando eles derem o OK, poderemos mudar facilmente. Vamos começar por aí.
Então, a pergunta é: como implementamos uma implantação azul-verde em nosso pipeline?
O que são slots de implantação?
Paulo: Como estamos usando o Serviço de Aplicativo do Azure, podemos aproveitar os slots de implantação. Os slots de implantação são aplicativos em execução que têm nomes de host próprios.
Sei que ainda não estamos prontos para implantar o site do Space Game para produção como parte do pipeline automatizado. Mas, como um teste, podemos adicionar um slot de implantação ao nosso ambiente de preparo.
Em vez de configurar um balanceador de carga ou um roteador, podemos apenas adicionar um segundo slot à instância do Serviço de Aplicativo que usamos em nosso ambiente de preparo existente. Podemos chamar o slot primário de azul e o slot secundário de verde.
Dessa forma, podemos implantar novos recursos sem nenhum tempo de inatividade. Trocamos um aplicativo e sua configuração entre os dois slots de implantação. Basicamente, estamos trocando os endereços IP dos dois slots.
Pedro: Gosto disso! Você pode chamar essa variação de implantação azul-verde em uma implantação sem tempo de inatividade.
Paulo: Legal! Pedro e eu trabalharemos na implementação desse padrão de implantação. Todos nós podemos nos encontrar depois para ver os resultados.
Recomendações para usar sinalizadores de recurso
Os sinalizadores de recurso foram um dos métodos de cadência de versão que a equipe considerou. A equipe decidiu não usar os sinalizadores de recurso, mas muitas pessoas os consideraram úteis. Esta seção fornece mais informações sobre os sinalizadores de recurso.
Os sinalizadores de recurso, às vezes chamados de alternâncias de funcionalidades, permitem que você altere como o sistema funciona sem alterar o código. Esses sinalizadores permitem que você efetue push do novo código para o branch de desenvolvimento central e tenha o código implantado, mas não necessariamente funcional. Os sinalizadores normalmente são implementados como o valor de variáveis que controlam a lógica condicional.
Imagine que sua equipe esteja trabalhando no branch de desenvolvimento central de um aplicativo bancário. Você decidiu fazer todo o trabalho na ramificação principal para evitar operações de mesclagem confusas mais tarde. Mas você enfrenta um problema. Você está alterando substancialmente os cálculos de juros e as pessoas dependem desse código todos os dias. Pior, as alterações levarão semanas para serem concluídas. Não é possível deixar o código principal interrompido por tanto tempo.
Nesse cenário, um sinalizador de recurso pode ser uma boa solução. Você pode alterar o código para que os usuários que não têm o sinalizador de recurso definido possam continuar usando o código de cálculo de juros original. Enquanto isso, sua equipe define o sinalizador de recurso, para que possa ver o código que está alterando.
Outro tipo de sinalizador de recurso é um sinalizador de versão. Imagine que depois de concluir o trabalho no código de cálculo de juros, você queira testá-lo antes de liberá-lo publicamente. Você tem um grupo de usuários que está bem posicionado para lidar com novos códigos e possíveis problemas. Você permitirá que eles experimentem o recurso primeiro. Você altera a configuração para que ele também tenha o sinalizador de recurso definido e possa testar o novo código. Se ocorrerem problemas, você poderá desabilitar o sinalizador rapidamente.