Implementando Blue-Green deployment com Deployment slots do Azure Web App

Você já passou pela experiência de planejar os seus deployments fora de horário comercial por causa da indisponibilidade que o deployment pode causar?

Ou então, depois de finalizar o deployment, você se deu conta de que a nova versão tem problemas que não deveriam chegar ao ambiente produtivo e precisou realizar um rollback para a versão anterior?

Neste artigo, eu quero mostrar uma solução simples para este problema utilizando a estratégia blue-green deployment com os deployment slots do Azure App Service.

O que são deployment slots?

Primeiramente, precisamos entender o que são os deployment slots e como eles podem nos auxiliar a aplicar a estratégia Blue-green.

Deployment slots é uma funcionalidade específica do recurso Azure App Service que facilita a implantação da aplicação seguindo a estratégia blue-green. Ele nos permite criar uma réplica, um ambiente duplicado atrelado ao Web App original que irá se comportar como um ambiente de preparação que irá receber novas versões da nossa aplicação.

E como isso se relaciona com a estratégia blue-green?

O blue-green é uma estratégia de deployment que consiste em termos uma réplica do ambiente produtivo, na qual iremos implantar as novas versões da aplicação. Depois da implantação, chaveiam-se os ambientes e todas as requisições para a aplicação são encaminhadas para esta nova versão, liberando assim o acesso a todos os usuários.

Uma de suas vantagens é que, em caso de erros na nova versão, basta redirecionar as requisições dos usuários de volta para a versão anterior.

Vou usar uma analogia para explicar melhor: Imagine que você tem 2 cozinhas em seu restaurante: uma azul e uma verde. A cozinha azul é utilizada para preparar as refeições e servir os seus clientes, enquanto a cozinha verde está passando por uma reforma. Quando a reforma da cozinha verde é finalizada, você volta a utilizá-la para preparar as refeições e servir seus clientes, e, se tudo correr bem, você então irá desativar a cozinha azul.

Vamos à prática

Para utilizar os deployment slots, é necessário criar um Web App atrelado a um App Service Plan na camada Standard, no mínimo. As camadas Premium e Isolated de precificação também oferecem a funcionalidade de Deployment Slots.

Para facilitar esta etapa, vamos usar o Azure CLI para criar os recursos.

Quero deixar uma explicação breve sobre o código de criação de recursos abaixo: da linha 1 até a linha 5, criamos variáveis que vão conter as informações dos recursos, como por exemplo, a região onde o recurso deve ser criado, o nome do grupo de recursos, do App Service Plan, do web app e do deployment slot. Você pode trocar os valores das variáveis de acordo com o nome que desejar para seus recursos.

Da linha 7 até a linha 10 do código, vamos criar o grupo de recursos, o App Service Plan, o Web App e o Deployment Slot acoplado ao Web App.

Os comandos acima podem ser executados diretamente no seu computador (após instalar o Azure CLI) ou no portal do Azure usando o cloud shell.

Depois de executar os comandos, esse é o resultado que esperamos no portal do Azure, com todos os recursos criados:

Logo após a criação dos recursos, o Web App (à esquerda) e o Deployment Slot (à direita) exibirão uma mensagem aguardando pelo código que será implantado neles, conforme a imagem abaixo:

Agora com a infraestrutura pronta, precisamos criar uma pipeline que fará a implantação (o deployment) da aplicação no Web App, e depois disso, fará a operação de troca do Web App com o Deployment Slot.

No código acima, temos as tarefas que farão as operações de deployment e troca de ambientes. Vamos focar nestas duas tarefas da pipeline por ora, mas disponibilizei o código completo da pipeline aqui e o código completo do projeto aqui.

A primeira tarefa da pipeline será utilizada para implantar a nossa aplicação no Web App. Nesta tarefa, o código da aplicação será enviado diretamente ao deployment slot chamado stage do Web App bgapp.

Depois que o código for implantado no deployment slot, na segunda tarefa vamos realizar a operação de troca dos ambientes (swap). Nesta etapa, trocamos o deployment slot stage de lugar com o Web App que está em produção, e então, disponibilizaremos aos nossos usuários a versão mais atual da aplicação.

Observe que neste cenário, sempre que tivermos uma implantação, a troca também acontecerá logo depois dela. Se desejar ou se for aplicável ao seu cenário, você também pode executar a operação de troca manualmente no portal do Azure.

É hora de testar!

Agora que finalizamos as implementações, configure e execute a pipeline diretamente no Azure DevOps pela primeira vez e valide então o resultado:

Após a primeira execução da pipeline, implantamos a versão da aplicação que contém a funcionalidade blue, como podemos confirmar na imagem acima.

Agora, iremos implementar a funcionalidade green e implantar novamente com a nossa pipeline. Altere o código fonte para exibir a funcionalidade green, faça o commit e o push para o Azure DevOps, e então, a pipeline será acionada pelas mudanças realizadas na branch main.

Durante a execução da pipeline, o código será implantando no deployment slot stage inicialmente:

E depois que a operação de troca de ambientes acontecer, teremos então o resultado final da nossa nova implementação:

À esquerda na imagem acima, temos o nosso ambiente produtivo do Web App com a versão da aplicação que contém a funcionalidade green. À direita, temos o slot stage com a versão anterior que contém a funcionalidade blue.

--

Espero que este conteúdo possa contribuir para sua jornada, e se você gostou, deixe um comentário ou entre em contato comigo no LinkedIn.

Até mais!