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 es