Colocar uma nova versão de projeto em produção requer um equilíbrio cuidadoso entre velocidade de implantação e confiabilidade da solução. O Slack valoriza iterações rápidas, ciclos curtos de feedback e resposta imediata às solicitações dos usuários. Além disso, a empresa conta com centenas de programadores que se esforçam para ser o mais produtivos possível.
Os autores do material, cuja tradução publicamos hoje, afirmam que uma empresa que se esforça para aderir a esses valores e ao mesmo tempo cresce deve melhorar constantemente seu sistema de implantação de projetos. A empresa precisa investir na transparência e confiabilidade dos processos de trabalho, garantindo que esses processos correspondam à escala do projeto. Aqui falaremos sobre os fluxos de trabalho que se desenvolveram no Slack e sobre algumas das decisões que levaram a empresa a utilizar o sistema de implantação de projetos que existe hoje.
Como funcionam os processos de implantação de projetos hoje
Cada PR (solicitação pull) no Slack deve estar sujeito à revisão de código e ser aprovado em todos os testes. Somente depois que essas condições forem atendidas o programador poderá mesclar seu código no branch master do projeto. No entanto, esse código é implantado apenas durante o horário comercial, horário da América do Norte. Como resultado, pelo fato de nossos colaboradores estarem em seus locais de trabalho, estamos totalmente preparados para solucionar quaisquer problemas inesperados.
Todos os dias realizamos cerca de 12 implantações planejadas. Durante cada implantação, o programador designado como líder de implantação é responsável por colocar a nova compilação em produção. Este é um processo de várias etapas que garante que a montagem entre em produção sem problemas. Graças a esta abordagem, podemos detectar erros antes que afetem todos os nossos usuários. Se houver muitos erros, a implantação do assembly poderá ser revertida. Se um problema específico for descoberto após o lançamento, uma correção poderá ser facilmente lançada para ele.
Interface do sistema Checkpoint, que é usado no Slack para implantar projetos
O processo de implantação de uma nova versão para produção pode ser considerado como consistindo em quatro etapas.
▍1. Criando um branch de lançamento
Cada lançamento começa com um novo branch de lançamento, um ponto em nossa história do Git. Isso permite atribuir tags ao lançamento e fornece um local onde você pode fazer correções em tempo real para bugs encontrados no processo de preparação do lançamento para lançamento em produção.
▍2. Implantação em um ambiente de teste
A próxima etapa é implantar o assembly em servidores de teste e executar um teste automático para o desempenho geral do projeto (teste de fumaça). O ambiente de teste é um ambiente de produção que não recebe tráfego externo. Neste ambiente, realizamos testes manuais adicionais. Isso nos dá confiança adicional de que o projeto modificado funciona corretamente. Os testes automatizados por si só não são suficientes para fornecer esse nível de confiança.
▍3. Implantação em ambientes dogfood e canary
A implantação na produção começa com um ambiente dogfood, representado por um conjunto de hosts que atendem nossos espaços de trabalho internos do Slack. Como somos usuários muito ativos do Slack, essa abordagem nos ajudou a detectar muitos bugs no início da implantação. Depois de nos certificarmos de que a funcionalidade básica do sistema não foi quebrada, o assembly é implantado no ambiente canário. Representa sistemas que respondem por aproximadamente 2% do tráfego de produção.
▍4. Liberação gradual para produção
Caso os indicadores de monitoramento da nova versão se mostrem estáveis, e se após a implantação do projeto no ambiente canário não tivermos recebido nenhuma reclamação, continuamos a transferir gradativamente os 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. Ao mesmo tempo, temos tempo para investigar a situação caso seja detectada alguma anomalia.
▍E se algo der errado durante a implantação?
Fazer modificações no código é sempre um risco. Mas lidamos com isso graças à presença de “líderes de implantação” bem treinados que gerenciam o processo de colocação de uma nova versão em produção, monitoram os indicadores de monitoramento e coordenam o trabalho dos programadores que liberam o código.
Caso algo realmente dê errado, tentamos detectar o problema o mais cedo possível. Investigamos o problema, encontramos o PR que está causando os erros, revertemos, analisamos minuciosamente e criamos uma nova compilação. É verdade que às vezes o problema passa despercebido até o projeto entrar em produção. Nessa situação, o mais importante é restaurar o serviço. Portanto, antes de começarmos a investigar o problema, voltamos imediatamente para a versão de trabalho anterior.
Blocos de construção de um sistema de implantação
Vejamos as tecnologias subjacentes ao nosso sistema de implantação de projetos.
▍Implantações rápidas
O fluxo de trabalho descrito acima pode parecer, em retrospecto, um tanto óbvio. Mas nosso sistema de implantação não ficou assim imediatamente.
Quando a empresa era muito menor, todo o nosso aplicativo podia ser executado em 10 instâncias do Amazon EC2. A implantação do projeto nessa situação significou usar o rsync para sincronizar rapidamente todos os servidores. Anteriormente, o novo código estava a apenas um passo da produção, representado por um ambiente de teste. As montagens foram criadas e testadas nesse ambiente e depois foram direto para produção. Foi muito fácil entender tal sistema; permitiu que qualquer programador implantasse o código que havia escrito a qualquer momento.
Mas à medida que o número de nossos clientes crescia, também crescia a escala da infraestrutura necessária para apoiar o projeto. Logo, dado o crescimento constante do sistema, nosso modelo de implantação, baseado em enviar novo código aos servidores, não estava mais funcionando. Ou seja, adicionar cada novo servidor significava aumentar o tempo necessário para concluir a implantação. Mesmo estratégias baseadas no uso paralelo de rsync têm certas limitações.
Acabamos resolvendo esse problema mudando para um sistema de implantação completamente paralelo, que foi projetado de forma diferente do sistema antigo. Ou seja, agora não enviamos código aos servidores usando um script de sincronização. Agora, cada servidor baixou independentemente o novo assembly, sabendo que precisava fazer isso monitorando a alteração da chave do Consul. Os servidores carregaram o código em paralelo. Isso nos permitiu manter uma alta velocidade de implantação mesmo em um ambiente de constante crescimento do sistema.
1. Os servidores de produção monitoram a chave Consul. 2. A chave muda, informa aos servidores que eles precisam começar a baixar o novo código. 3. Os servidores baixam 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 multicamadas foi a implantação atômica.
Antes de usar implantações atômicas, cada implantação poderia resultar em um grande número de mensagens de erro. O fato é que o processo de cópia de novos arquivos para servidores de produção não era atômico. Isso resultou em um curto espaço de tempo em que o código que chamava novas funções estava disponível antes que as próprias funções estivessem disponíveis. Quando esse código foi chamado, resultou no retorno de erros internos. Isso se manifestou em solicitações de API com falha e páginas da web quebradas.
A equipe que trabalhou neste problema resolveu-o introduzindo o conceito de diretórios “quentes” e “frios”. O código no diretório quente é responsável pelo processamento do tráfego de produção. E em diretórios “frios”, o código, enquanto o sistema está rodando, está apenas sendo preparado para uso. Durante a implantação, o novo código é copiado para um diretório frio não utilizado. Então, quando não houver processos ativos no servidor, uma troca instantânea de diretório será executada.
1. Descompactando o código do aplicativo em um diretório “frio”. 2. Mudar o sistema para um diretório “frio”, que passa a ser “quente” (operação atômica)
Resultados: mudança de ênfase para confiabilidade
Em 2018, o projeto cresceu a tal escala que uma implantação muito rápida começou a prejudicar a estabilidade do produto. Tínhamos um sistema de implantação muito avançado no qual investimos muito tempo e esforço. Tudo o que precisávamos fazer era reconstruir e melhorar nossos processos de implantação. Tornámo-nos numa empresa bastante grande, cujos desenvolvimentos têm sido utilizados em todo o mundo para organizar comunicações ininterruptas e resolver problemas importantes. Portanto, a confiabilidade tornou-se o foco de nossa atenção.
Precisávamos tornar o processo de implantação de novas versões do Slack mais seguro. Essa necessidade nos levou a melhorar nosso sistema de implantação. Na verdade, discutimos esse sistema aprimorado acima. Nas profundezas do sistema, continuamos a usar tecnologias de implantação rápida e atômica. A forma como a implantação é feita mudou. Nosso novo sistema foi projetado para implantar gradualmente novo código em diferentes níveis, em diferentes ambientes. Agora usamos ferramentas de suporte e ferramentas de monitoramento de sistema mais avançadas do que antes. Isso nos dá a capacidade de detectar e corrigir erros muito antes que eles cheguem ao usuário final.
Mas não vamos parar por aí. Estamos constantemente aprimorando este sistema, utilizando ferramentas auxiliares e ferramentas de automação de trabalho mais avançadas.
Caros leitores! Como funciona o processo de implantação de novas versões de projetos onde você trabalha?
Fonte: habr.com