Por que o Slot de QA não é mais o lugar certo para o Rollback
Chegou mais uma segunda-feira, dia de entrega, e com ela, a rotina de deploy. Nosso processo padrão envolve subir a nova versão em QA e, em seguida, fazer o swap para produção. Simples, certo? Não exatamente. Acontece que o ambiente de QA, que deveria ser um espelho da produção para validação final, começou a ser usado para testes diversos, por diferentes equipes. Isso significa que, no momento crucial do swap, a versão que esperávamos encontrar em QA para garantir um rollback seguro, muitas vezes, já não era a versão estável que havíamos validado. Uma dor de cabeça que precisava ser resolvida antes que se tornasse um problema maior.
O problema
A dor era clara: a falta de um ambiente imutável para rollback. Nosso processo de deploy, que dependia do ambiente de QA para um swap seguro, estava vulnerável. Se algo desse errado em produção, a versão em QA poderia não ser a versão estável anterior, impossibilitando um rollback rápido e seguro. Precisávamos de um "porto seguro", um slot de deploy que guardasse a versão estável da produção, intocável, para qualquer eventualidade.
A investigação
Minha primeira dedução foi que precisávamos de um novo slot de implantação, dedicado exclusivamente para ser um fallback. Sem rota configurada, sem uso para testes, apenas um guardião da versão estável. A jornada começou na Azure, nosso provedor de serviços em nuvem. Naveguei até o App Service, onde nossas aplicações residem, e então para os slots de implantação da aplicação em questão. Tudo via interface gráfica, um legado que ainda estamos trabalhando para modernizar com IaC, mas que, por enquanto, é o caminho.
Criei o slot e o batizei de fallback. A ideia era que ele serviria apenas para subir a versão nova e fazer o swap para produção. Em caso de necessidade de rollback, ele estaria lá, imutável, com a versão que estava em produção antes do deploy. Parecia um plano sólido.
Com o slot criado, o próximo passo era ajustar o Azure DevOps. Nossas configurações de swap ainda apontavam para QA, e isso precisava mudar. Fui em Releases, selecionei a release que estávamos trabalhando (ainda em modo clássico, outro ponto para futuras melhorias com YAML) e cliquei em editar. Para agilizar, clonei o stage de deploy para QA, mas o deixei sem trigger, para ser executado apenas manualmente. O ponto crucial aqui foi trocar o Slot de QA para fallback.
Em seguida, na task que realiza o swap para produção, alterei o Source Slot de QA para fallback. Confirmei que o checkbox Swap with Production estava ativo. Nesse momento, senti que estávamos no caminho certo. Salvei as alterações e o trabalho, por enquanto, estava feito. Agora era esperar a próxima entrega para validar se tudo funcionaria como o esperado.
Chegou a segunda-feira, dia da entrega. 8:40 da manhã, o deploy agendado para as 09:00. Dei uma última lida na documentação que havíamos feito, para me certificar de que não havia esquecido de nada. O plano era claro: verificar a versão em produção, subir a nova versão no slot fallback, fazer o swap para produção e, por fim, verificar se a versão havia sido trocada. Acontece kkk, que a teoria é uma coisa, a prática é outra.
O Microsoft Azure App Service, no processo de swap, troca o código (artefato) e algumas configurações (dependendo do que está marcado como "slot setting"). A lógica é:
Com o plano em mãos, executei os passos. Subi o projeto no slot fallback e, em seguida, realizei o swap.
Ufa, deu certo! A versão foi atualizada com sucesso e o slot fallback agora continha a versão anterior, pronta para um rollback caso necessário. A tensão diminuiu, e a sensação de ter resolvido um problema crítico foi gratificante.
Ficou em aberto
Embora a solução para o problema do slot de fallback tenha sido implementada com sucesso, ainda há um caminho a percorrer. A dependência da interface gráfica da Azure e o uso de releases em modo clássico no Azure DevOps são pontos que precisam ser endereçados. A transição para IaC (Infrastructure as Code) e a conversão das releases para arquivos YAML versionados são os próximos passos para modernizar nossa infraestrutura e processos, garantindo maior automação e controle.
Referências
Azure App Service - Slots de Implantação - documentação oficial sobre como configurar e realizar o swap entre slots de produção e staging
Azure DevOps - Release Pipelines (Clássico) - guia sobre a criação e edição de pipelines de release no modo clássico
Azure App Service - Configurações de Slot - detalhes técnicos sobre quais configurações de artefatos e variáveis são trocadas durante o swap
Vinicius Aguilar — DevOps Engineer
