A implementação de uma nova versão do projeto em produção requer um cuidadoso equilíbrio entre a velocidade de implantação e a confiabilidade da solução. Na empresa Slack, eles valorizam iterações rápidas, ciclos de feedback curtos e uma resposta ágil às solicitações dos usuários. Além disso, a empresa conta com centenas de programadores que buscam alcançar a máxima produtividade possível.
Os autores do material, cuja tradução publicamos hoje, afirmam que uma empresa que busca manter esses valores e ainda crescer deve constantemente aprimorar seu sistema de implantação de projetos. A empresa deve investir esforços na transparência e confiabilidade dos processos de trabalho, garantindo que esses processos estejam à altura da escala do projeto. Neste contexto, falaremos sobre os processos de trabalho estabelecidos na Slack e algumas soluções que levaram a empresa a adotar o sistema de implantação de projetos que existe atualmente.
Como os processos de implantação de projetos funcionam hoje
Cada PR (pull request) na Slack deve passar obrigatoriamente por revisão de código e deve passar por todos os testes com sucesso. Somente após o cumprimento dessas condições é que o programador pode mesclar seu código com o branch master do projeto. No entanto, a implantação desse código é realizada apenas durante o horário comercial por tempo norte-americano. Como resultado, estamos totalmente preparados para resolver quaisquer problemas inesperados, já que nossos funcionários estão em seus postos de trabalho.
Todos os dias, realizamos cerca de 12 implantações programadas. Durante cada implantação, o programador designado como responsável pela implantação é encarregado de levar uma nova versão para a produção. Este é um processo em várias etapas que garante uma transição suave da versão para o modo ativo. Com essa abordagem, conseguimos identificar erros antes que eles afetem todos os nossos usuários. Se houver muitos erros, a implantação da versão pode ser revertida. No entanto, se um problema específico for detectado após o lançamento, uma correção pode ser rapidamente emitida para ele.
A interface do sistema Checkpoint, que é utilizada na Slack para a implantação de projetos
O processo de implantação de uma nova versão em produção pode ser descrito em quatro etapas.
▍1. Criação de uma branch de release
Cada release começa com uma nova branch de release, a partir de um ponto na nossa história do Git. Isso permite nomear o release com tags e dá um espaço onde podem ser feitas correções rápidas para problemas encontrados durante a preparação do release para a produção.
▍2. Implantação em ambiente intermediário
O próximo passo é implantar a build nos servidores intermediários (staging) e realizar um teste automático de funcionalidade geral do projeto (smoke test). O ambiente intermediário é um ambiente de produção que não recebe tráfego externo. Nesse ambiente, realizamos testes manuais adicionais. Isso nos dá confiança extra de que o projeto modificado está funcionando corretamente. Testes automatizados sozinhos não são suficientes para adquirir tal confiança.
▍3. Implantação em ambientes dogfood e canary
A implantação em produção começa com o ambiente dogfood, que consiste em um conjunto de hosts que atendem nossas áreas de trabalho internas no Slack. Como somos usuários bem ativos do Slack, utilizar essa abordagem ajudou a identificar muitos erros nas primeiras fases de implantação. Após garantirmos que a funcionalidade básica do sistema não foi afetada, a build é implantada no ambiente canary. Este representa sistemas que recebem cerca de 2% do tráfego de produção.
▍4. Gradual lançamento em produção
Se os indicadores de monitoramento da nova versão se mostraram estáveis, e se após a implantação do projeto no ambiente canary não recebemos reclamações, continuamos a migração gradual dos servidores de produção para a nova versão. O processo de implantação é dividido nas seguintes etapas: 10%, 25%, 50%, 75% e 100%. Como resultado, podemos transferir lentamente o tráfego de produção para a nova versão do sistema. Assim, temos tempo para investigar a situação caso algumas anomalias sejam detectadas.
▍O que fazer se algo der errado durante a implantação?
Modificar o código sempre envolve riscos. Mas conseguimos lidar com isso graças à presença de nossos bem-preparados "responsáveis pela implementação", que lideram o processo de lançamento de uma nova versão em produção, monitoram os indicadores e coordenam o trabalho dos programadores que liberam o código.
Caso algo realmente dê errado, nos esforçamos para identificar o problema o mais cedo possível. Investigamos a questão, encontramos o PR que causa os erros, reverte o mesmo, analisamos cuidadosamente e criamos uma nova build. No entanto, às vezes o problema passa desapercebido até que o projeto seja colocado em produção. Nessa situação, o mais importante é restaurar o funcionamento do serviço. Portanto, antes de começar a investigar o problema, imediatamente reverteremos para a última build funcional.
Blocos de construção do sistema de implementação
Vamos analisar as tecnologias que fundamentam nosso sistema de implementação de projetos.
▍Implementações rápidas
O fluxo de trabalho descrito acima pode parecer, em retrospectiva, algo completamente óbvio. Mas nosso sistema de implementação não se tornou assim imediatamente.
Quando a empresa era muito menor, todo nosso aplicativo podia funcionar em 10 instâncias Amazon EC2. A implementação do projeto, nessa situação, significava usar rsync para uma rápida sincronização de todos os servidores. Antes, novo código em produção estava separado por apenas um passo, representado por um ambiente intermediário. As builds eram criadas e testadas nesse ambiente e iam direto para a produção. Era muito fácil entender esse sistema, permitindo que qualquer programador implementasse o código por ele escrito a qualquer momento.
Mas à medida que o número de nossos clientes crescia, também crescia a escala da infraestrutura necessária para suportar o projeto. Logo, considerando o crescimento constante do sistema, nosso modelo de implementação, baseado em enviar novo código para os servidores, deixou de ser eficiente. Especificamente, adicionar cada novo servidor significava um aumento no tempo necessário para a implementação. Mesmo estratégias que utilizam a aplicação paralela de rsync têm certas limitações.
Como resultado, resolvemos este problema ao migrar para um sistema de implantação completamente paralelo, que não funciona como o antigo. Agora, em vez de enviar o código para os servidores com um script de sincronização, cada servidor carrega a nova versão de forma autônoma, por meio do monitoramento da alteração da chave Consul. Os servidores fazem o download do código em paralelo. Isso nos permitiu manter uma alta velocidade de implantação, mesmo em um ambiente de crescimento contínuo do sistema.
1. Os servidores de produção monitoram a chave Consul. 2. Quando a chave muda, isso informa aos servidores que eles devem iniciar o download do novo código. 3. Os servidores fazem o download de arquivos tarball com o código do aplicativo.
▍Implantações atômicas
Outra solução que nos ajudou a alcançar um sistema de implantação em múltiplos níveis foi a implantação atômica.
Antes de adotarmos implantações atômicas, cada implantação poderia resultar em muitos erros. O problema era que o processo de cópia de novos arquivos para os servidores de produção não era atômico. Isso criava uma breve janela de tempo em que o código que chamava novas funções se tornava disponível antes que as próprias funções estivessem prontas. Quando esse código era acionado, resultava em erros internos. Isso se manifestava em solicitações de API falhadas e em páginas da web 'quebradas'.
A equipe que lidou com esse problema o resolveu introduzindo diretórios 'quentes' (hot) e 'frios' (cold). O código no diretório 'quente' é responsável pelo processamento do tráfego de produção. Nos diretórios 'frios', o código, enquanto o sistema está em funcionamento, apenas se prepara para uso. Durante a implantação, o novo código é copiado para o diretório 'frio', que não está em uso. Em seguida, quando não houver processos ativos no servidor, ocorre uma troca instantânea de diretórios.
1. Descompactação do código do aplicativo no diretório 'frio'. 2. Troca do sistema para o diretório 'frio', que se torna 'quente' (operação atômica).
Resultados: mudança de foco para a confiabilidade.
Em 2018, o projeto alcançou uma escala em que o rápido lançamento começou a prejudicar a estabilidade do produto. Tínhamos um sistema de implantação bastante avançado, no qual investimos muito esforço e tempo. Precisávamos apenas reestruturar e aprimorar os processos de organização da implantação. Nós nos tornamos uma empresa de porte considerável, cujas soluções eram utilizadas em todo o mundo para garantir comunicações contínuas e resolver questões importantes. Por isso, a confiabilidade se tornou o nosso foco principal.
Precisávamos tornar o processo de implantação de novas versões do Slack mais seguro. Essa necessidade nos levou a aprimorar nosso sistema de implantação. De fato, discutimos anteriormente este sistema aprimorado. Dentro da sistemática, continuamos utilizando tecnologias de implantação rápida e atômica. O que mudou foi a forma como a implantação é executada. Nosso novo sistema é projetado para realizar a implantação de novo código de maneira gradual, em diferentes níveis e ambientes. Agora, utilizamos ferramentas auxiliares e recursos de monitoramento mais avançados do que antes. Isso nos permite detectar e corrigir erros muito antes que eles tenham a chance de chegar ao usuário final.
Mas não pretendemos parar por aqui. Estamos constantemente aprimorando esse sistema, aplicando ferramentas auxiliares mais sofisticadas e meios de automação.
Prezados leitores! Como é o processo de implantação de novas versões dos projetos onde você trabalha?
Fonte: habr.com
