Como acelerar seu pipeline de CI/CD

O mercado moderno é um ambiente hipermoderno, em constante mudança e em constante crescimento. Todos os dias, milhares de novos concorrentes são criados em todo o mundo, a tecnologia transformadora abala as indústrias no seu núcleo e novos paradigmas estão a abrir caminho para fazer negócios.

Neste contexto, as entregas rápidas são mais importantes do que nunca e os clientes querem que os seus projetos correspondam às exigências de um mercado competitivo que avança a uma velocidade vertiginosa. Entrega e Desenvolvimento Contínuos (CI/CD) é uma metodologia popular que busca fazer exatamente isso, automatizando o processo de desenvolvimento e criando um ciclo constante.

Mas mesmo um método projetado para acelerar seu ciclo de desenvolvimento pode ter seu quinhão de gargalos, e é sobre isso que falaremos hoje. O que podemos fazer para otimizar nosso pipeline de CI/CD.

Construa apenas o que você precisa

Pode ser tentador tentar forçar o máximo possível em cada commit, mas construir cinco módulos ou serviços diferentes de uma só vez pode muitas vezes levar a mais problemas do que vale a pena.

Uma boa política é que cada commit seja como um bom e-mail, curto e direto ao ponto. Mesmo projetos baseados em arquitetura monolítica têm muito a ganhar ao aderir a um módulo de cada vez.

Concentre seus esforços no que é absolutamente necessário, priorize e mantenha a simplicidade. Comprometimentos massivos muitas vezes podem atuar como gargalos devido a revisões de código, controle de qualidade e testes. Se 99% do código for perfeito, mas uma única linha gerar um sinalizador, o restante do código poderá ficar preso no processo enquanto o bug é corrigido.

Se isso soa como alguém vendendo arquiteturas de microsserviços, bem, é exatamente isso. Embora as abordagens monolíticas tenham seus próprios pontos fortes, geralmente manter tudo micro e compartimentado economizará muito tempo no longo prazo.

Evite fazer muitas alterações de recursos de uma só vez

Um pouco de continuação do ponto anterior. Mudanças de recursos são necessárias, mas, ao mesmo tempo, representam um risco. Do ponto de vista do desenvolvimento de software, com cada mudança de recurso corremos o risco de bugar nosso código ou introduzir consequências não intencionais.

Do ponto de vista do usuário, muitas alterações podem confundir o usuário final e é mais difícil avaliar quais alterações estão funcionando e quais não estão, se todas forem apresentadas ao mesmo tempo. Pior ainda, você corre o risco de uma mudança desagradável estragar toda a atualização, pois as pessoas tendem a generalizar experiências ruins.

Assim como acontece com a construção de novos módulos, se um recurso falhar no teste, o restante dos recursos deverá ser colocado em espera enquanto você encontra o culpado. Para piorar a situação, quanto mais você mudou, mais difícil será encontrar a origem do problema.

Vale repetir, a melhor forma de evitar esse tipo de gargalo é pensar pequeno, uma mudança de cada vez mantém as coisas organizadas e são mais fáceis de manusear para toda a equipe.

Executar trabalhos em paralelo

Os pipelines de CI/CD podem economizar muito tempo quando usados ​​corretamente, mas, assim como um pipe, eles só conseguem lidar com um limite. Após um certo limite, o ciclo contínuo entra em colapso e um gargalo é formado.

Para aqueles que não são muito experientes em desenvolvimento de software, as etapas de construção mais comuns são executadas sequencialmente. Ou seja, cada etapa é executada sozinha e só acontece após a conclusão da etapa anterior.

Às vezes podemos dividir o processo em etapas individuais e executá-las ao mesmo tempo, isso é comumente conhecido como execução em paralelo ou simultaneamente. Cinco trabalhos que levam um minuto para serem concluídos levariam cinco minutos para serem concluídos em sequência e apenas um minuto se executados em paralelo.

Obviamente, nem todo trabalho pode ser executado em paralelo, nem é necessário. Alguns trabalhos são rápidos ou eficientes o suficiente para lidar com a carga de trabalho. Outros trabalhos podem exigir mais tempo e recursos e, nesses casos, o processo pode ser acelerado criando outras instâncias para execução em conjunto.

Cache, Cache, Cache

Artefatos de versões anteriores de CI/CD podem ser reutilizados durante novos ciclos. Por exemplo, um pacote ou contêiner exigido pelo seu aplicativo pode ser usado em ciclos subsequentes.

Para evitar ter que baixar ou reconstruir completamente seu pool de recursos para cada ciclo, você deve armazenar tudo em cache e reutilizá-lo sempre que possível. Existem ferramentas fantásticas para este tipo de tarefa, como por exemplo o Artifactory.

Ao reutilizar recursos que você já tem em mãos, você pode aumentar significativamente a velocidade do seu pipeline de CI/CD. Ao mesmo tempo, você reduz os riscos de problemas decorrentes de problemas de compatibilidade no futuro.

Embora os caches sejam úteis, eles não devem ser usados ​​para sempre. É importante excluir seu cache ao atualizá-los ou quando eles não forem mais necessários, para evitar confusão no futuro.

Use versões Canary

Algumas equipes de DevOps lançam versões prévias para um pequeno subconjunto de usuários e coletam feedback antes de se comprometerem totalmente com uma versão. As versões Canary podem ajudá-lo a coletar dados úteis sobre suas alterações sem expor toda a sua base de usuários a possíveis bugs ou problemas.

Grandes equipes de desenvolvimento podem até criar diferentes versões canário, cada uma voltada para um subconjunto diferente de usuários. Dessa forma, diferentes alterações podem ser avaliadas em paralelo e possíveis problemas podem ser detectados mais facilmente.

Por exemplo, se você tiver três grupos de usuários de amostra, A, B e C, e o grupo A estiver relatando um bug, você saberá que algo está acontecendo especificamente com essa versão canário. Dessa forma, é mais fácil rastrear a origem do problema.

Analise seu pipeline

Deixamos o melhor para o final. Não podemos enfatizar o quão importante é para uma equipe monitorar constantemente seu pipeline de CI/CD. Meça quanto tempo cada ciclo está demorando e observe atentamente os trabalhos que estão demorando mais.

O tempo está sendo usado em etapas de alto valor? Se não for esse o caso, o que você pode fazer para reduzir o tempo total ou reorganizar suas etapas?

Existem passos longos que não estão agregando valor? Por que eles estão no lugar? Eles podem ser removidos com segurança?

Ao compreender seu próprio pipeline, você poderá tomar melhores decisões sobre como aumentar a velocidade de cada ciclo. Lembre-se de que projetar um pipeline de CI/CD é um processo iterativo. Você deve continuar trabalhando nisso e monitorando-o constantemente para encontrar áreas de melhoria.