É necessário proibir a implantação na produção em determinados momentos? Ou o movimento #NoDeployFriday se tornou uma relíquia dos tempos em que não havia testes de integração abrangentes e implantação contínua?

Na sua equipe, você pode enfrentar o mesmo dilema. Quem está certo e quem é o culpado? Abandonar a implantação às sextas-feiras é uma estratégia razoável para reduzir riscos ou é uma cultura ruim que nos impede de criar sistemas melhores e mais estáveis?

Ding ding

Tenho certeza de que os engenheiros que tiveram a sorte de estar "em contato" perderam seus dias de folga por causa de todas as mudanças que ocorreram na sexta-feira. Eu também estava nessa situação. Uma ligação quando você sai com sua família ou no meio da noite, notificando-o sobre a falha do aplicativo. Depois de entrar no computador e verificar os logs de crescimento rápido, torna-se óbvio que tudo foi arruinado por uma exceção rara e sem tratamento. Nojento.

A análise revela que, para o cenário que levou à falha, nenhum teste foi escrito, aparentemente por não ser considerado provável. Após uma série de longas ligações telefônicas com outros engenheiros em busca de uma maneira melhor de reverter as alterações e consertar tudo, o sistema começa a funcionar novamente. Fuh.

Uma reunião de cinco razões é realizada na segunda-feira.

" Vamos parar de implantar às sextas-feiras. Então, no fim de semana, tudo funcionará de maneira estável, e na próxima semana estaremos em alerta após todos os tipos de lançamentos ".

Todo mundo assente. Se algo não entrar em operação antes do meio-dia de quinta-feira, ele aguardará até segunda-feira de manhã. Essa abordagem prejudica ou ajuda?


Como você sabe, as declarações do Twitter geralmente são muito subjetivas. Embora a proibição de lançamentos na sexta-feira pareça razoável, alguém rapidamente apontará que isso é apenas uma muleta por causa da fragilidade da plataforma, causada por maus processos de teste e implantação.

Alguns até sugerem que você goste de implantações silenciosas mais do que o próprio fim de semana:


Outros usuários acreditam que a implementação de sinalizadores de função pode ser uma solução possível.


Esse usuário acredita que os problemas de uma implantação arriscada não devem surgir devido aos processos e ferramentas disponíveis hoje.

Quem toma as decisões?

Toda essa troca de opiniões indica que nós, como uma comunidade de engenheiros, podemos discordar totalmente e não necessariamente concordamos um com o outro. Quem teria pensado. Essa situação provavelmente também demonstra que a imagem geral de #NoDeployFriday contém nuances que não são muito bem refletidas no Twitter. É verdade que todos devemos aplicar a implantação contínua, caso contrário, “fazemos errado”?

Ao tomar tal decisão, há um aspecto psicológico. A hostilidade aos lançamentos de sexta-feira vem do medo de cometer erros durante a semana (devido a fadiga ou pressa), que podem causar danos enquanto a maioria dos funcionários descansa por dois dias. Como resultado, um commit de sexta-feira contendo um problema em potencial pode estragar o fim de semana para muitas pessoas: engenheiros de serviço, outros engenheiros que ajudarão remotamente a resolver o problema e, possivelmente, especialistas em infraestrutura que precisam recuperar dados danificados. Se a falha for séria, outros funcionários da empresa também poderão estar envolvidos na situação, que precisará entrar em contato com os clientes e minimizar os danos.

Assumindo a posição de idealista, podemos assumir que, em um mundo ideal, com código perfeito, cobertura de teste perfeita e controle de qualidade perfeito, nenhuma mudança pode levar a um problema. Mas nós somos pessoas, e as pessoas tendem a cometer erros. Sempre haverá alguns casos de fronteira estranhos que não são fechados durante o desenvolvimento. Isso é vida Portanto, o movimento #NoDeployFriday faz sentido, pelo menos teoricamente. No entanto, isso é apenas uma ferramenta cega. Acredito que é necessário avaliar as alterações feitas de acordo com a situação e, a priori, é necessário proceder do fato de que implantamos em qualquer dia, mesmo às sextas-feiras, mas ao mesmo tempo deve ser capaz de isolar as alterações que devem esperar até segunda-feira.

Existem algumas questões que podemos discutir. Dividi-os em categorias:

1. Entendendo o "raio de destruição" da mudança.
   
2. A solidez do processo de implantação.
   
3. A capacidade de detectar erros automaticamente.
   
4. Quanto tempo leva para resolver problemas.
   

Agora vamos discutir.

Entendendo o "raio da destruição"

Quando as lanças on-line sobre os lançamentos de sexta-feira começam a quebrar novamente, elas sempre esquecem o importante - a natureza das mudanças. Não há alterações idênticas na base de código. Alguns commits controlam a interface um pouco e nada mais; outros refatoram centenas de classes sem afetar a funcionalidade do programa; outros ainda alteram os esquemas do banco de dados e fazem grandes alterações no processo de consumo de dados em tempo real; as quarta podem reiniciar uma instância, enquanto as quintas podem iniciar uma reinicialização em cascata de todos os tipos de serviços.

Olhando para o código, os engenheiros devem ter uma boa idéia do "raio de destruição" das mudanças feitas. Que parte do código e do aplicativo será afetada? O que poderia cair se o novo código travar? É apenas um clique em um botão que gera um erro ou todas as novas entradas serão perdidas? Foi feita uma alteração em um único serviço isolado ou muitos serviços e dependências serão alterados simultaneamente?

Não consigo imaginar quem se recusará a fazer alterações com um pequeno "raio de destruição" e uma implantação simples em qualquer dia da semana. Mas, ao mesmo tempo, grandes mudanças - especialmente aquelas relacionadas à infraestrutura de armazenamento - devem ser realizadas com mais cuidado, talvez em um momento em que haja menos usuários online. Será ainda melhor se essas mudanças em larga escala forem colocadas em operação em paralelo para testar e avaliar seu trabalho sob carga real, e ninguém saberá disso.

Aqui você precisa tomar decisões, dependendo da situação. Todo engenheiro está ciente do "raio de destruição" das mudanças no ambiente de produção, e não apenas no ambiente de desenvolvimento? Se não, por que? É possível melhorar a documentação, o treinamento e a exibição dos efeitos das alterações de código na produção?

O "raio de destruição" é pequeno? Lançamento na sexta-feira.

O "raio de destruição" é grande? Aguarde até segunda-feira.

A solidez do processo de implantação

Uma maneira de reduzir riscos é melhorar continuamente o processo de implantação. Se, para iniciar uma versão nova do aplicativo, ainda é necessário que um especialista saiba qual script executar, qual arquivo e onde copiar, é hora de iniciar a automação. Nos últimos anos, as ferramentas nessa área avançaram muito. Geralmente usamos o Jenkins Pipeline and Concourse , eles permitem que você defina diretamente os pipelines de montagem, teste e implantação com código.

O processo de implantação completa da implantação é uma coisa interessante. Ele permite que você dê um passo atrás e tente abstrair o que deve acontecer a partir do momento em que a solicitação de recebimento é inicializada até o aplicativo ser colocado em operação. Uma descrição de todas as etapas do código, por exemplo, nas ferramentas mencionadas acima, ajudará você a generalizar as definições de etapas e reutilizá-las em todos os aplicativos. Além disso, será interessante observar algumas decisões estranhas ou preguiçosas com as quais você uma vez tomou e se reconciliou.

A cada engenheiro que leu os dois parágrafos anteriores e reagiu no estilo de “Bem, é claro! Fazemos isso há anos! Posso garantir que outras 9 pessoas apresentaram sua infraestrutura de aplicativos e fizeram uma careta, percebendo a quantidade de trabalho que precisa ser feito para transferir o sistema para um pipeline de implantação moderno. Isso implica tirar proveito das ferramentas modernas que não apenas realizam a integração contínua, mas também permitem que você forneça bugs continuamente ao produto, e os engenheiros precisam apenas pressionar o botão para comissionar (ou até fazê-lo automaticamente, se você for corajoso o suficiente).

Melhorar o transportador de implantação requer envolvimento e equipe apropriada - esse definitivamente não é um projeto paralelo. Uma boa solução seria destacar uma equipe para melhorar as ferramentas internas. Se eles ainda não souberem dos problemas existentes - e provavelmente sabem -, será possível coletar informações sobre as situações mais dolorosas associadas ao processo de liberação, priorizar e corrigi-las juntamente com outras pessoas. Lentamente, mas com certeza, a situação melhorará: o código entrará em operação mais rapidamente e com menos problemas. Mais e mais pessoas poderão aprender melhores abordagens e fazer melhorias por conta própria. À medida que a situação melhorar, as abordagens serão distribuídas em equipes, e este novo projeto será concluído corretamente, sem a cópia usual dos velhos maus hábitos.

A partir do momento da mesclagem, a solicitação de recebimento do commit deve ser automatizada para que você nem precise pensar nisso. Isso não apenas ajuda a isolar os problemas reais no controle de qualidade, porque a única variável é o código alterado, mas torna a escrita do código muito mais agradável. O comissionamento é descentralizado, o que aumenta a autonomia e a responsabilidade pessoal. E isso, por sua vez, leva a decisões mais deliberadas sobre quando e como lançar o novo código.

Transportador de implantação confiável? Lançamento na sexta-feira.

Copiando scripts manualmente? Aguarde até segunda-feira.

Capacidade de detectar erros

O comissionamento não para depois que o código começa a funcionar. Se algo der errado, precisamos saber sobre isso, e é aconselhável que sejamos informados sobre isso, e não tenhamos que procurar informações sozinhas. Para fazer isso, é necessário verificar automaticamente os logs do aplicativo em busca de erros, rastrear explicitamente as principais métricas (por exemplo, o número de mensagens processadas por segundo ou a porcentagem de erros), além de um sistema de aviso que informe os engenheiros sobre problemas críticos e mostre uma tendência negativa para determinadas métricas.

A operação é sempre diferente do desenvolvimento, e os engenheiros precisam monitorar a operação de certas partes do sistema. Você precisa responder a perguntas sobre cada alteração subseqüente: isso acelerou ou desacelerou o sistema? Há mais ou menos tempos limite? Somos limitados por processador ou E / S?

Dados sobre métricas e erros devem ser transmitidos ao sistema de aviso. As equipes devem poder determinar quais sinais indicam uma situação negativa e enviar mensagens automáticas sobre isso. Para nossas equipes e os incidentes mais graves, usamos o PagerDuty.

Medir as métricas do sistema de produção significa que os engenheiros podem ver se algo mudou após cada implantação, para melhor ou para pior. E nos piores casos, o sistema informará automaticamente alguém sobre o problema.

Bom monitoramento, notificações e especialistas de plantão? Implante na sexta-feira.

Visualizar logs manualmente via ssh? Aguarde até segunda-feira.

Quanto tempo leva para resolver problemas?

Finalmente, o principal critério é quanto tempo levará para corrigir os problemas. Isso depende em parte do "raio de dano" das alterações feitas. Mesmo se você tiver um pipeline de implantação lambido, algumas alterações são difíceis de corrigir rapidamente. A reversão de alterações no sistema de extração de dados e no esquema do índice de pesquisa pode exigir uma reindexação trabalhosa, além de corrigir alguma linha de código. A duração média de uma implantação, validação, correção e reimplementação de alterações de CSS pode ser de minutos, enquanto as principais alterações no repositório podem exigir dias de trabalho.

Para todas as obras no pipeline de implantação, que no nível da macro podem aumentar a confiabilidade das alterações, nenhuma alteração é a mesma; portanto, é necessário avaliá-las separadamente. Se algo der errado, podemos corrigi-lo rapidamente?

É totalmente corrigido com uma única confirmação de restauração? Implante na sexta-feira.

Existem grandes dificuldades se algo der errado? Aguarde até segunda-feira.

Pense por si mesmo, decida por si mesmo

Qual é a minha posição no #NoDeployFriday? Eu acho que tudo depende do lançamento. Alterações com um pequeno "raio de acerto" fácil de reverter podem ser implementadas a qualquer hora, em qualquer dia. Com grandes mudanças, cujo impacto deve ser monitorado de perto no sistema de produção, recomendo esperar até segunda-feira.

De fato, cabe a você implantar às sextas-feiras. Se você estiver trabalhando com um sistema frágil e estridente, é melhor evitar as sextas-feiras até ter feito todo o necessário para melhorar o processo de implantação. Apenas certifique-se de fazê-lo, não escove. Recusar lançamentos de sexta-feira é uma maneira normal de encobrir falhas temporárias de infraestrutura. Essa é uma redução razoável de danos para o bem dos negócios. Mas é ruim se essa regra cobrir falhas constantes.

Se você não tiver certeza do efeito que as alterações terão, adie para segunda-feira. Mas pense no que você pode fazer da próxima vez para entender melhor esse efeito e melhorar a infraestrutura associada para isso. Como sempre na vida, cada decisão tem suas próprias nuances. As soluções não são divididas em “preto” e “branco”, em “certo” e “errado”: ​​enquanto fazemos tudo o que podemos para negócios, aplicativos e entre si, melhorando nossos sistemas, estamos fazendo tudo bem.

Implantação bem sucedida.