Eliminar o tempo de inatividade por meio de atualizações de serviço versionadas

Historicamente, os administradores precisavam colocar um servidor offline para atualizar e fazer upgrade do software local. No entanto, a indisponibilidade é completamente inviável para serviços globais 24x7. Muitos serviços de nuvem modernos são uma dependência crítica para os usuários executarem seus negócios. Nunca há um bom momento para reduzir um sistema, então como uma equipe pode fornecer serviço contínuo ao instalar atualizações importantes de segurança e recursos?

Usando atualizações versionadas, esses serviços críticos podem ser transferidos diretamente de uma versão para outra enquanto os clientes os estão usando ativamente. Nem todas as atualizações são difíceis. Atualizar layouts ou estilos de front-end é fácil. As alterações nos recursos podem ser complicadas, mas há práticas conhecidas para reduzir os riscos de migração. No entanto, as alterações que emanam da camada de dados introduzem uma nova classe de desafios que exigem consideração especial.

Atualizar camadas separadamente

Com um serviço online distribuído em vários datacenters e armazenamento de dados separado, nem tudo pode mudar simultaneamente. Se o serviço típico for dividido em código do aplicativo e bancos de dados, que presumivelmente são versionados independentemente um do outro, um desses lados precisa absorver a complexidade do tratamento do versionamento.

Geralmente, o controle de versão é mais fácil de lidar no código do aplicativo. Sistemas maiores geralmente têm um pouco de código herdado, como o SQL que reside dentro de seus bancos de dados. Em vez de complicar ainda mais esse SQL, o código do aplicativo deve lidar com a complexidade. Especificamente, você pode criar um conjunto de classes de fábrica que entendam o controle de versão do SQL.

Durante cada sprint, crie uma nova interface com essa versão para que sempre haja um código que corresponda a cada versão do banco de dados. Você pode facilmente reverter quaisquer binários durante a implantação. Se algo der errado depois de implantar os novos binários, reverta para o código anterior. Se a implantação binária for bem-sucedida, inicie a manutenção do banco de dados.

Então, como isso realmente funciona? Por exemplo, suponha que sua equipe esteja implantando o Sprint 123 no momento. Os binários entendem o esquema de banco de dados Sprint 123 e entendem o esquema Sprint 122. O padrão geral é trabalhar com as versões/sprints N e N-1 do esquema SQL. Os binários consultam o banco de dados, determinam com qual versão de esquema estão conversando e, em seguida, carregam a associação apropriada. Em seguida, o código do aplicativo manipula o caso quando o novo esquema de dados ainda não está disponível. Depois que a nova versão estiver disponível, o código do aplicativo poderá começar a usar a nova funcionalidade habilitada pela versão mais recente do banco de dados.

Avançar apenas com a camada de dados

Depois que os bancos de dados forem atualizados, o serviço estará em uma situação "roll forward" se ocorrer um problema. As migrações de banco de dados online são complexas e, muitas vezes, várias etapas, portanto, avançar é geralmente a melhor maneira de resolver um problema. Em outras palavras, se a atualização falhar, a reversão provavelmente também falhará. Há pouco valor em investir no esforço para criar e testar o código de reversão que sua equipe nunca espera usar.

Sequência de implantação

Considere um cenário em que você precisa adicionar um conjunto de colunas a um banco de dados e transformar alguns dados. Essa transição deve ser invisível para os usuários, o que significa evitar bloqueios de tabela sempre que possível e, em seguida, manter esses bloqueios pelo menor tempo possível para que não sejam perceptíveis.

A primeira coisa que fazemos é manipular os dados, possivelmente em tabelas paralelas usando um gatilho SQL para manter os dados sincronizados. As migrações e transformações de dados grandes às vezes precisam ser várias etapas em várias implantações em vários sprints.

Depois que os dados extras ou o novo esquema tiverem sido criados em paralelo, a equipe entrará no modo de implantação do código do aplicativo. No modo de implantação, quando o código faz uma chamada para o banco de dados, ele primeiro pega um bloqueio no esquema e o libera depois de executar o procedimento armazenado. O banco de dados não pode alterar entre a hora em que a chamada para o banco de dados é emitida e quando o procedimento armazenado é executado.

O código de atualização funciona como um escritor de esquema e solicita um bloqueio de escritor no esquema. O código do aplicativo tem prioridade na tomada de um bloqueio de leitura e o código de atualização permanece em segundo plano tentando adquirir o bloqueio de escrita. No bloqueio de escrita, apenas um pequeno número de operações muito rápidas são permitidas nas tabelas. Em seguida, o bloqueio é liberado e o aplicativo registra que a nova versão do banco de dados está em uso e usa a interface que corresponde à nova versão do banco de dados.

As atualizações de banco de dados são todas executadas usando um padrão de migração. Um conjunto de códigos e scripts analisa a versão do banco de dados e, em seguida, faz alterações incrementais para migrar o esquema do antigo para a nova versão. Todas as migrações são automatizadas e distribuídas por meio do serviço de gerenciamento de lançamento.

A interface do usuário da Web também deve ser atualizada sem interromper os usuários. Ao atualizar arquivos JavaScript, folhas de estilo ou imagens, evite misturar versões antigas e novas sendo carregadas pelo cliente. Isso pode levar a erros que podem perder o trabalho em andamento, como um campo sendo editado por um usuário. Portanto, você deve versionar todos os arquivos JavaScript, CSS e imagem, colocando-os em uma pasta separada, cada uma com sua própria versão, para cada implantação. Quando a interface web do usuário faz chamadas de volta para a camada de aplicação, os ativos com uma versão especificada são carregados. Somente quando uma ação do usuário resulta em uma atualização de página inteira a nova interface do usuário da Web é carregada no navegador. A experiência do usuário não é interrompida pela atualização.

Próximas etapas

A Microsoft tem sido uma das maiores empresas de desenvolvimento de software do mundo há décadas. Saiba como a Microsoft opera sistemas confiáveis com o DevOps.