Um conto de moralidade

Era uma vez um grande e terrível navio pirata que governava o alto mar, apesar de ter um pouco de vazamento. A tripulação frequentemente tinha que bombear água do mar para fora dos conveses inferiores após uma tempestade ou uma luta. Um dia, após uma batalha particularmente violenta, eles perceberam que balas de canhão haviam rompido o casco abaixo da linha d'água. Eles não sabiam como consertá-lo sem ferramentas ou carpinteiros. Então, eles simplesmente conectaram as bombas para funcionarem constantemente, dia e noite. Por um tempo, isso manteve o ritmo, mas logo eles tiveram que comprar o dobro das bombas e trazer mais marinheiros para equipar as bombas enquanto outros navegavam. Em pouco tempo, eles tinham mais marinheiros operando bombas do que realmente navegando no navio ou saqueando e pilhando. Não foi para isso que eles se inscreveram, o que deixou todo mundo muito irritado. Em pouco tempo, eles se tornaram especialistas em tudo que tinha a ver com bombear água de navios, mas suas outras habilidades de velejar, saquear e saquear foram prejudicadas e seus melhores funcionários partiram frustrados. Antes que o ano terminasse, o navio deles havia afundado.

A moral da história é: não trate os sintomas: trate a causa.

Falando nisso, vamos falar sobre CI / CD.

CI / CD (integração contínua e entrega / implantação contínua) faz parte da nossa vida. Vamos a conferências sobre CI / CD, escrevemos artigos e blogamos sobre CI / CD, listamos CI / CD em nossa página do LinkedIn. Ninguém discute se é a coisa certa a fazer ou não. Estamos todos na mesma página. Direito? 

Exceto ... se você ouvir com atenção o que as pessoas estão dizendo, elas não estão falando sobre CI / CD - elas podem dizer “CI / CD”, mas estão apenas falando sobre integração contínua. Ninguém está falando sobre (ou praticando) implantação contínua. EM ABSOLUTO. É como se todos tivéssemos esquecido que ele existe.

Não me interpretem mal, é maravilhoso termos melhorado em CI na última década. Mas não é o suficiente. Não é nem metade da batalha. O objetivo da integração contínua era nunca se sentir orgulhoso da correção sintática e logicamente integrada de nosso software, embora isso seja um bom bônus. O objetivo da CI é limpar o caminho e preparar o terreno para a entrega contínua, porque o CD é o que realmente salvará sua pele . 

Assim como naquele navio pirata, você precisa tratar as causas em vez de perseguir os sintomas. E qual é a principal fonte desses vazamentos e buracos em nosso (arr!) Navio pirata de produção? É tudo o que acontece entre o momento em que você escreve o código e o momento em que o código está ativo: seu sistema digestivo de software muito longo, com vazamentos, distendido, inchado, amontoado e com falhas.

Err… o que é CI / CD, realmente?

Ótima pergunta. Que bom que você perguntou. CI / CD é um processo e uma metodologia desenvolvida para garantir que todo o código que você mesclar com o principal seja implementável a qualquer momento, testando-o e implementando-o. Automaticamente. Após cada diferença.

O objetivo do CI / CD é reduzir o tempo de espera das alterações de software para um intervalo curto o suficiente para que nossos sistemas de aprendizagem humanos (adrenalina, dopamina, etc.) possam mapear os ciclos de feedback da escrita e envio do código.

Se algum engenheiro de sua equipe puder mesclar um conjunto de alterações em principal, tenha a certeza de que 15 minutos depois suas alterações serão testadas e implantadas em produção, sem a necessidade de portas humanas ou intervenção manual, então parabéns! Você está fazendo CI / CD.

Muito poucas equipes estão realmente praticando CI / CD, mas quase todas deveriam estar. Esta é a higiene básica do software.

A espiral da morte do desenvolvimento de software

O tempo decorrido entre a escrita e o envio é a placa de Petri temporária, onde os sintomas patológicos se reproduzem e se multiplicam. Prazos de entrega mais longos levam a diferenças de código maiores e revisões de código mais lentas. Isso significa que qualquer um revisando ou revisando essas diferenças de pesadelo tem que pausar e trocar o contexto completo dentro e fora de sua mente sempre que mudar de marcha, desde escrever código para revisar e vice-versa. 

Assim, o ciclo de feedback elástico do ciclo de desenvolvimento começa a se estender cada vez mais, à medida que as pessoas passam mais e mais tempo esperando umas às outras - para revisar, comentar, implantar, fazer alterações solicitadas - e cada vez mais tempo no estado de paginação dentro e fora de seus cérebros e tentando lembrar onde estavam e o que estavam tentando fazer.

Mas fica pior. A maioria das implantações é executada manualmente, em algum intervalo indeterminado depois que o código foi escrito, não pela pessoa que escreveu o código e - o pior de tudo - com muitas alterações dos desenvolvedores agrupadas de uma vez. É isso, acima de tudo, que separa o engenheiro dos efeitos de seu trabalho e torna impossível para ele praticar a propriedade responsável durante todo o ciclo de vida de seu código.

Agrupar as alterações significa que você não pode praticar o desenvolvimento orientado pela observabilidade; você não pode esperar que os engenheiros vejam o código deles saindo e garantam que ele esteja funcionando na produção. Você não sabe quando seu código está saindo e não sabe quem é o responsável por uma mudança no comportamento de produção; portanto, você não tem responsabilidade ou autonomia e não pode praticar a propriedade do software sobre seu próprio código. No final das contas, seus engenheiros gastarão uma porcentagem maior de seu tempo esperando, se atrapalhando ou lidando com dívidas de tecnologia, sem levar o negócio adiante.

Como muitos de seus engenheiros existentes estão ocupados, você precisará contratar muito mais deles, o que acarreta custos de coordenação mais altos. Em breve, você precisará de funções especializadas, como SRE, ops, QA, engenheiros de construção, etc. para ajudá-lo a combater heroicamente cada um dos sintomas de forma isolada. Então, você precisará de mais gerentes e TPMs e assim por diante. Adivinha! Agora você é uma empresa grande e cara e pesa como um dinossauro.

Ele fica mais lento, então fica mais difícil e complicado, então você precisa de mais recursos para gerenciar a complexidade e combater os efeitos colaterais, o que cria ainda mais complexidade e área de superfície. Esta é a espiral mortal do desenvolvimento de software. Mas existe outra maneira. Você pode corrigir o problema na origem, concentrando-se implacavelmente no período de tempo entre o momento em que uma linha de código é escrita e quando ela é totalmente implantada para produção. Fixe nesse intervalo, automatize esse intervalo, rastrei

e esse intervalo, dedique recursos reais de engenharia para reduzi-lo ao longo do tempo. 

Até que esse intervalo seja curto o suficiente para ser um ciclo de feedback funcional, tudo o que você fará é controlar os sintomas de disfunção. Quanto maior o atraso, mais esses sintomas aparecerão e mais tempo suas equipes gastarão tentando resolver os vazamentos.

Quão curto? 15 minutos é ótimo, menos de uma hora é provavelmente bom. A previsibilidade é tão importante quanto o comprimento, e é por isso que os portões humanos são um desqualificador. Mas se o seu intervalo atual for algo como 15 dias, anime-se - qualquer esforço que você fizer para reduzir esse intervalo terá retorno. Qualquer melhoria paga dividendos. 

É aqui que muitas pessoas parecem duvidosas. “Não tenho certeza se minha equipe pode lidar com isso”, podem dizer. “Tudo isso é muito bom e bom para o Facebook ou Google, mas não somos eles”. 

A maneira como você está fazendo agora é da maneira mais difícil

Isso pode surpreendê-lo, mas a implantação contínua é, de longe, a maneira mais fácil de escrever, enviar e executar código na produção. Esta é a verdade contra-intuitiva sobre software: fazer muitas pequenas mudanças rapidamente é infinitamente mais fácil do que fazer algumas mudanças pesadas lentamente. 

Pense desta maneira. Qual desses bugs seria mais fácil para você localizar, entender, reproduzir e corrigir: um bug no código que você sabe que escreveu hoje ou um bug no código que alguém de sua equipe provavelmente escreveu no ano passado?

Não é nem perto! Você nunca, nunca mais irá depurar ou entender este código tão bem como agora, com sua intenção original fresca em seu cérebro, sua compreensão do problema e seu espaço de solução rico e fresco. 

Ao escrever seu código, você deve instrumentá-lo com um olho em seu próprio futuro daqui a meia hora: “Como você será capaz de dizer se seu código está fazendo o que você queria ou não?” Você escreve o código, mescla com o principal, espera alguns minutos e abre sua ferramenta de observação para visualizar a produção através das lentes de sua instrumentação. Pergunte a si mesmo: "está fazendo o que deveria fazer?" e "algo mais parece ... estranho?"

As equipes que reduzem esse ritmo geralmente encontram 80% de todos os bugs ali mesmo. Está fresco na sua cabeça, você está preparado para procurar as coisas certas, você está instrumentando no local. Se algo der errado ou não parecer certo, você pode criar outro diff imediatamente.

Por outro lado, as equipes que não têm prática de implantações rápidas e não estão acostumadas a olhar para as mudanças na produção, bem, elas não encontram esses bugs. (Seus clientes sim.)

A propósito, sim, não é exatamente fácil pegar um aplicativo que é enviado mensalmente e fazer com que ele seja entregue dez vezes por dia. Mas é surpreendentemente fácil iniciar um aplicativo com entrega contínua desde o início e mantê-lo assim, nunca deixando que passe de 15 minutos de lead time. Como Alexandre, o Grande, pegando seu cavalo todas as manhãs antes do café da manhã, dificilmente parece trabalho. 

Portanto, se mover seus aplicativos legados para o CD parece um trabalho muito pesado agora, você poderia pelo menos iniciar qualquer novo repositório ou serviço ou aplicativo com o CD desde o início? Qualquer CD é melhor do que nenhum CD. Mesmo que parte do seu código seja implantado automaticamente após as alterações, você aplicará muitos bons padrões à sua equipe, como preservar a compatibilidade retroativa entre as versões.

O desafio nº 1 para liderança técnica em 2021

Por que tão poucas equipes priorizam a entrega contínua? As virtudes de um prazo de entrega curto e ciclos de feedback estreitos são tão dramáticas, amplamente conhecidas e bem compreendidas que eu nunca entendi isso. Mas agora acho que sim.

O problema é que isso parece um problema de pessoas, não um problema técnico. Portanto, isso é classificado como um problema de gerenciamento. E os gerentes estão acostumados a resolver problemas de gerenciamento com ferramentas de gerenciamento, como solicitar mais funcionários.

Também pode ser difícil de vender para a alta administração. Você está pedindo a eles que aceitem um atraso em seu roteiro de recursos no curto prazo e possivelmente menos confiabilidade por um período indeterminado de tempo, a fim de implementar algo que vai absolutamente contra nossos instintos humanos básicos, que nos dizem para desacelerar para aumentar segurança.

Em geral, os engenheiros parecem estar cientes do valor da entrega contínua, e muitos estão desesperados para trabalhar em equipes que se movam com a maior rapidez e confiança possível com CI / CD. Se você está tentando contratar mais engenheiros, é um ótimo recrutamento. Mais importante, faz com que sua equipe use os ciclos de engenharia existentes de maneira mais eficiente.

Gostaria de terminar com um apelo aos gerentes e diretores de engenharia em todo o mundo. Você gostaria que suas equipes fossem apaixonadas e engajadas, trabalhando em todos os cilindros, produzindo na capacidade máxima, gastando o mínimo de tempo no combate a incêndios ou cuidando de pagamentos de dívidas técnicas vencidas ou aguardando as revisões uns dos outros?

Você gostaria que os membros da sua equipe olhassem para trás e se lembrassem de você com saudade e carinho, como alguém que mudou a maneira como pensavam sobre o desenvolvimento de software - alguém que sempre elevou a barra aos olhos deles? Nossos destinos estão em suas mãos.

As equipes que conseguiram CI / CD não o fizeram porque são melhores engenheiros do que o resto de nós. Eu prometo. São equipes que prestam mais atenção ao processo do que o resto de nós. Grandes equipes formam grandes engenheiros, e não vice-versa.

A entrega contínua ajuda seus engenheiros a controlar o código em produção, mas também oferece muitos outros benefícios colaterais. Ele força você a fazer todas as coisas certas - escrever pequenas diferenças, revisar o código rapidamente, instrumentar sua intenção original da mesma forma que você comenta seu código, usar sinalizadores de recurso, desacoplar implantações e versões, etc.

Você pode passar sua vida importunando as pessoas para que limpem seus códigos e sigam todas as práticas recomendadas separadamente, ou você pode apenas focar na redução desse ciclo de feedback e observar todo o resto se encaixar por conta própria. 

É difícil? Sim, é difícil. Mas espero ter convencido você de que vale a pena fazer . É uma mudança de vida. É a nossa ponte para os sistemas sociotécnicos de amanhã, e mais de nós precisamos dar esse salto. Qual é o seu plano para alcançar CI / CD em 2021?

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.