🐃 📊 👩🏿 Metodologia de implantação de projeto usada pelo Slack 👩🏿‍⚕️ 💆🏿 🆎

A conclusão de um novo lançamento de projeto em produção requer um balanceamento cuidadoso entre a velocidade de implantação e a confiabilidade da solução. O Slack aprecia iterações rápidas, breves ciclos de feedback e capacidade de resposta às solicitações do usuário. Além disso, a empresa possui centenas de programadores que buscam a maior produtividade possível.

Os autores do material, cuja tradução publicamos hoje, afirmam que uma empresa que busca 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, a fim de garantir que esses processos correspondam ao escopo do projeto. Aqui, falaremos sobre os processos de trabalho desenvolvidos no Slack e sobre algumas das soluções que levaram a empresa a usar o sistema de implantação de projetos que existe hoje.

Como os processos de implantação do projeto funcionam hoje

Cada PR (solicitação de recebimento) no Slack deve ser submetido a uma revisão de código e deve passar em todos os testes com êxito. Somente após essas condições serem atendidas, um programador pode mesclar seu código com a ramificação principal do projeto. No entanto, a implantação desse código é realizada apenas durante o horário comercial, de acordo com o horário da América do Norte. Como resultado, nós, devido ao fato de nossos funcionários estarem no trabalho, estamos totalmente preparados para resolver quaisquer problemas inesperados.

Todos os dias, concluímos cerca de 12 implantações planejadas. Durante cada implantação, o programador, designado como a implantação principal, é responsável por trazer o novo assembly para produção. Este é um processo de várias etapas, que fornece uma conclusão suave da montagem no modo de trabalho. Graças a essa abordagem, podemos detectar erros antes que eles afetem todos os nossos usuários. Se houver muitos erros, a implantação da montagem poderá ser revertida. Se um problema específico for detectado após o lançamento, uma correção poderá ser facilmente liberada.

A interface do sistema Checkpoint usado pelo Slack para implantar projetos.O

processo de implantar um novo release na produção pode ser representado em quatro etapas.

▍1 Criando uma ramificação de liberação

Cada lançamento começa com um novo ramo de lançamento, a partir do momento em nossa história do Git. Isso permite atribuir tags à liberação e fornece um local onde você pode fazer correções operacionais para erros encontrados no processo de preparação da liberação para liberação na produção.

§ 2 Implantação intermediária

A próxima etapa é implantar a montagem nos servidores temporários e executar um teste automático para o desempenho geral do projeto (teste de fumaça). Um ambiente intermediário é um ambiente de produção em que o tráfego externo não cai. Nesse ambiente, realizamos testes manuais adicionais. Isso nos dá confiança adicional de que o projeto modificado está funcionando corretamente. Testes automatizados por si só não são suficientes para ganhar tanta confiança.

▍3 Implantação em alimentos para cães e ambientes canários

A implantação na produção começa com um ambiente de dogfood representado por um conjunto de hosts que atendem aos nossos espaços de trabalho internos do Slack. Como somos usuários muito ativos do Slack, o uso dessa abordagem ajudou a detectar muitos erros nos estágios iniciais da implantação. Depois de garantir que a funcionalidade básica do sistema não seja interrompida, a montagem é implantada em um ambiente canário. É um sistema que recebe cerca de 2% do tráfego de produção.

▍4 Conclusão gradual na produção

Se os indicadores de monitoramento da nova versão se mostrarem estáveis, e se após a implantação do projeto no ambiente canário não recebermos reclamações, continuaremos a transferência gradual de servidores de produção para a nova versão. O processo de implantação é dividido nos seguintes estágios: 10%, 25%, 50%, 75% e 100%. Como resultado, podemos transferir lentamente o tráfego de produção para uma nova versão do sistema. Ao mesmo tempo, temos tempo para investigar a situação no caso de revelar algumas anomalias.

▍E se algo desse errado durante a implantação?

Fazer modificações no código é sempre um risco. Mas podemos lidar com isso graças aos nossos bem treinados "gerentes de implantação", que gerenciam o processo de introdução de uma nova versão em produção, monitoram o desempenho do monitoramento e coordenam o trabalho dos programadores que lançam o código.

No caso de algo realmente dar errado, tentamos detectar o problema o mais cedo possível. Investigamos o problema, localizamos o PR que causa os erros, revertê-lo, analisá-lo cuidadosamente e criar uma nova montagem. É verdade que às vezes o problema passa despercebido antes que o projeto seja colocado em produção. Em tal situação, o mais importante é restaurar o serviço. Portanto, antes de iniciar a investigação do problema, reverteremos imediatamente para a montagem de trabalho anterior.

Blocos de construção da implantação

Considere 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, algo completamente óbvio. Mas nosso sistema de implantação não ficou tão longe imediatamente.

Quando a empresa era significativamente menor, todo o nosso aplicativo podia ser executado em 10 instâncias do Amazon EC2. A implantação de um projeto nessa situação significava usar o rsync para sincronizar rapidamente todos os servidores. Anteriormente, o novo código era separado da produção por apenas uma etapa, representada por um ambiente intermediário. As montagens foram criadas e testadas em um ambiente como esse e depois foram direto para a produção. Entender esse sistema era muito simples, pois permitia a qualquer programador implantar o código que ele escreveu a qualquer momento.

Porém, à medida que o número de nossos clientes cresceu, também aumentou a escala da infraestrutura necessária para garantir a operação do projeto. Logo, dado o constante crescimento do sistema, nosso modelo de implantação, baseado no envio de novo código para os servidores, deixou de lidar com sua tarefa. Ou seja, a adição de cada novo servidor significou um aumento no tempo necessário para concluir a implantação. Mesmo estratégias baseadas no uso paralelo do rsync têm certas limitações.

Como resultado, resolvemos esse problema mudando para um sistema de implantação totalmente paralelo, que não é organizado como o sistema antigo. Nomeadamente, agora não enviamos o código aos servidores usando o script de sincronização. Agora, cada servidor baixou independentemente uma nova montagem, sabendo que precisava ser feita, graças à observação da alteração da chave do Consul. Os servidores baixaram 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 está mudando; isso informa aos servidores que eles precisam iniciar o download do novo código. 3. Os servidores enviam arquivos tarball com o código do aplicativo

Implantações atômicas

Outra solução que nos ajudou a chegar a um sistema de implantação em vários níveis 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 copiar novos arquivos para servidores de produção não era atômico. Isso levou à existência de um curto espaço de tempo quando o código no qual as novas funções foram chamadas estava disponível antes que as próprias funções se tornassem disponíveis. Quando esse código foi chamado, ele retornou erros internos. Isso foi manifestado em solicitações de API malsucedidas e em páginas da Web quebradas.

A equipe que lidou com esse problema resolveu o problema introduzindo o conceito de diretórios "quente" (quente) e "frio" (frio). O código no diretório "quente" é responsável pelo processamento do tráfego de produção. E nos diretórios "cold", o código, enquanto o sistema está em execução, está apenas se preparando para o uso. Durante a implantação, o novo código é copiado para o diretório "frio" não utilizado. Então, quando não há processos ativos no servidor, os diretórios são alternados instantaneamente.

1. Descompacte o código do aplicativo em um diretório "frio". 2. Alternando o sistema para um diretório "frio", que fica "quente" (operação atômica)

Conclusão: uma mudança na ênfase na confiabilidade

Em 2018, o projeto cresceu a tal ponto 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 investíamos muito tempo e esforço. Precisávamos apenas reestruturar e melhorar os processos da organização de implantação. Nós nos tornamos uma empresa bastante grande, cujo desenvolvimento foi usado em todo o mundo para organizar a comunicação ininterrupta e resolver problemas importantes. Portanto, o foco de nossa atenção foi a confiabilidade.

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. De fato, discutimos acima esse sistema aprimorado. Nas entranhas do sistema, continuamos a usar tecnologias de implantação rápida e atômica. Alterado como exatamente a implantação é realizada. Nosso novo sistema foi projetado para implantar gradualmente o novo código em diferentes níveis, em diferentes ambientes. Agora, usamos ferramentas auxiliares e mais avançadas do que antes, para monitorar o sistema. Isso nos dá a oportunidade de capturar e eliminar erros muito antes que eles tenham a chance de alcançar o usuário final.

Mas não vamos parar por aí. Estamos constantemente aprimorando esse sistema usando ferramentas auxiliares e ferramentas de automação mais avançadas.

Queridos leitores! Como é o processo de implantação de novos lançamentos de projetos em que você trabalha?

Metodologia de implantação de projeto usada pelo Slack