Medindo e monitorando o desempenho de CI/CD
A melhoria contínua é um dos pilares da filosofia DevOps.
Ela se estende a todos os aspectos do desenvolvimento de software, desde o produto ou serviço que você está construindo até a cultura e os processos de sua organização.
A melhoria contínua envolve a coleta e análise de feedback sobre o que você construiu ou como está trabalhando, a fim de entender o que está funcionando bem e o que pode ser melhorado. Depois de aplicar esses insights, você coleta mais feedback para ver se as alterações feitas movem o ponteiro na direção certa e, em seguida, continua a fazer ajustes conforme necessário.
Um pipeline de CI/CD desempenha um papel central na melhoria contínua do seu software. Ao encurtar o tempo do desenvolvimento à implantação, você poderá lançar alterações para os usuários com mais frequência e, assim, obter feedback do uso na produção, que informa o que você deve priorizar em seguida. Da mesma forma, o feedback rápido fornecido em cada estágio do teste automatizado facilita a correção de bugs e ajuda você a manter a qualidade do seu software.
Mas a melhoria contínua não para por aí. Aplicando as mesmas técnicas ao próprio pipeline de CI/CD, você pode refinar o processo de build, testes e lançamento de seu software, o que amplifica os ciclos de feedback que você usa para melhorar seu produto.
Entendendo as métricas do pipeline
“Você não pode gerir o que você não mede”, como diz o ditado.
Métricas são uma ferramenta essencial para melhorar o desempenho do sistema – ajudam a identificar onde você pode agregar valor e oferecem uma base sobre a qual pode-se medir o impacto de quaisquer melhorias que você fizer.
O desempenho em CI/CD abrange velocidade e qualidade; não deve haver um trade-off entre implantar mudanças rapidamente e entregar um produto robusto e confiável: um pipeline de CI/CD de alto desempenho deve permitir que você entregue ambos.
Ao medir e monitorar a velocidade das atividades, a qualidade do seu software e até que ponto você está usando a automação, você poderá identificar as áreas que podem ser melhoradas e depois confirmar se as mudanças que você fez tiveram um efeito positivo.
Métricas de desempenho de alto nível para DevOps
As quatro métricas a seguir foram identificadas pelo DevOps Research and Assessment (DORA) como métricas de alto nível que fornecem uma indicação precisa do desempenho de uma organização no contexto de desenvolvimento de software.
You can learn more about the research that informed these choices in the book Accelerate.
Lead time
Embora o tempo "lead time" (também conhecido como tempo de entrega ou tempo de mercado) possa ser medido como o tempo desde o momento em que um recurso é gerado pela primeira vez até ser lançado para os usuários, o tempo envolvido na concepção, pesquisa do usuário e prototipagem tende a ser altamente variável.
Por este motivo, a abordagem adotada pelo DORA é medir o tempo desde o commit do código até sua implantação, o que permite que você se concentre apenas nos estágios que estão dentro do escopo de seu pipeline de CI/CD.
Um lead time longo significa que você não está recebendo alterações de código diante dos usuários com regularidade e, portanto, não está se beneficiando do feedback para refinar o que está construindo. Isto pode ser devido a vários fatores.
Um pipeline de lançamento que envolve etapas manuais, como um grande número de testes manuais, avaliações de risco ou painéis de revisão de mudanças, pode acrescentar dias ou até semanas ao processo, minando as vantagens dos lançamentos frequentes.
Embora o investimento em testes automatizados seja a solução para o primeiro problema, o último requer o envolvimento das partes interessadas para entender como suas necessidades poderiam ser atendidas de forma mais eficiente. Como alternativa, se as etapas automatizadas forem lentas ou não confiáveis, as métricas de duração do build podem ser usadas para identificar os estágios que levam mais tempo.
Frequência de implantação
A frequência de implantação registra o número de vezes que você usa o pipeline de CI/CD para implantar em produção. A frequência de implantação foi selecionada pelo DORA como um proxy para o tamanho do lote, pois uma alta frequência de implantação implica menos alterações por implantação.
A implantação de um pequeno número de mudanças freqüentemente reduz o risco associado à liberação (porque há menos variáveis que podem se combinar em resultados inesperados) e fornece feedback mais cedo.
Uma baixa frequência de implantação pode significar que o pipeline não está sendo alimentado com commits regulares, talvez porque as tarefas não estão sendo divididas, ou pode ser o resultado de alterações em lote em lançamentos maiores.
Quando as alterações precisam ser agrupadas por motivos comerciais (por exemplo, devido às expectativas do usuário), medir a frequência das implantações nos sites de staging permitirá que você monitore o tamanho do lote e avalie se está colhendo os benefícios de trabalhar em pequenos incrementos.
Taxa de falha de alterações
A taxa de falha de alterações refere-se à proporção de alterações implantadas na produção que resultaram em uma falha, como uma interrupção ou bug que requer um rollback ou hotfix. A vantagem dessa métrica é que ela coloca as implantações com falha no contexto do volume de alterações feitas.
Uma baixa taxa de falhas de alterações deve trazer confiança ao seu pipeline; indica que os estágios anteriores do pipeline estão fazendo seu trabalho e detectando a maioria dos defeitos antes que seu código seja implantado em produção.
Tempo médio de recuperação
O tempo médio de recuperação ou resolução (MTTR) mede o tempo que leva para resolver uma falha de produção. O MTTR reconhece que, em um sistema complexo com muitas variáveis, algumas falhas em produção são inevitáveis. Em vez de buscar a perfeição (e, portanto, desacelerar os lançamentos e perder os benefícios dos lançamentos frequentes), é mais importante responder aos problemas rapidamente.
Manter baixo o seu MTTR requer o tanto monitoramento proativo do sistema em produção, para alertá-lo sobre os problemas à medida que surgem, como a capacidade de fazer rollback de alterações ou implantar uma correção rapidamente através do pipeline.
Uma métrica relacionada, tempo médio de detecção (MTTD), mede o tempo entre a implantação de uma mudança e a detecção de um problema introduzido por essa mudança no sistema de monitoramento. Ao comparar o MTTD e a duração do build, você pode determinar se alguma das áreas se beneficiaria de investimentos para reduzir seu MTTR.
Métricas operacionais e de CI
Além dessas medidas de alto nível, há uma variedade de métricas operacionais que você pode usar para entender melhor como está o desempenho do seu pipeline e identificar áreas onde você poderia melhorar seu processo.
Cobertura de código
Em um pipeline de CI/CD, os testes automatizados devem fornecer a maior parte da cobertura de testes, liberando seus engenheiros de QA para se concentrarem em testes exploratórios e na definição de novos casos de teste. A primeira camada de testes automatizados executados deve ser a camada de testes de unidade, pois são os mais rápidos de executar e fornecem o feedback mais imediato.
A cobertura de código é uma métrica fornecida pela maioria dos servidores de CI que calcula a proporção de seu código coberto por testes de unidade. Vale a pena monitorar essa métrica para garantir que você mantenha uma cobertura de testes adequada à medida em que escreve mais código. Se sua cobertura de código está diminuindo ao longo do tempo, é hora de investir algum esforço nesta primeira linha de feedback.
Duração do build
A duração ou tempo de build mede o tempo necessário para concluir as várias etapas do pipeline automatizado. Analisar o tempo gasto em cada estágio do processo é útil para identificar pontos problemáticos ou gargalos que podem estar diminuindo o tempo geral que leva para obter feedback dos testes ou implantação em produção.
Taxa de sucesso de testes
A taxa de sucesso de testes é a porcentagem de casos de teste que passaram com sucesso em um determinado build. Enquanto você tiver um nível razoável de testes automatizados, você terá uma boa indicação da qualidade de cada build. Você pode usar essa métrica para entender a frequência com que as alterações de código resultam em testes com falha.
Embora detectar falhas com testes automatizados seja preferível, em vez de confiar em testes manuais ou descobrir problemas na produção, se um determinado conjunto de testes automatizados falhar regularmente, pode valer a pena examinar a causa raiz dessas falhas.
Tempo para corrigir os testes
O tempo para corrigir os testes é o tempo entre o instante que um build relata um teste com falha e o mesmo teste passando com sucesso num build subsequente. Esta métrica fornece uma indicação da rapidez com que você consegue responder aos problemas identificados no pipeline.
Um tempo de resolução baixo mostra que você está usando seu pipeline para obter os melhores resultados; ao lidar com os problemas assim que eles são encontrados, você poderá trabalhar com mais eficiência (já que as alterações ainda estão frescas em sua mente) e evitar a construção de funcionalidades adicionais sobre o código instável.
Implantações com falha
Implantações com falha que resultam em tempo de inatividade não intencional, requerem que a implantação seja revertida ou que uma correção seja lançada com urgência. A contagem de implantações com falha é usada para calcular a taxa de falhas de alterações (discutida acima).
O monitoramento da proporção de falhas em relação ao número total de implantações ajuda a medir seu desempenho em relação aos SLAs.
No entanto, tenha em mente que uma meta de zero (ou muito poucas) implantações com falha não é necessariamente realista e pode, em vez disso, encorajar as equipes a priorizar a certeza. Isto resulta em prazos de entrega mais longos e implantações maiores à medida que as alterações são agrupadas, o que, na verdade, aumenta a probabilidade de falhas na produção (já que há mais variáveis) e as torna mais difíceis de corrigir (já que há mais alterações para percorrer).
Contagem de defeitos
Ao contrário das falhas, uma contagem de defeitos se refere ao número de tickets abertos no seu backlog que são classificados como bugs. Ele pode ser subdividido em problemas encontrados nas fases de testes ou staging e problemas encontrados em produção.
Assim como a cobertura de código, monitorar o número de defeitos é útil para alertá-lo sobre uma tendência geral de aumento, que pode indicar que os bugs estão saindo do controle. Lembre-se, entretanto, de que tornar essa métrica uma meta pode fazer com que sua equipe concentre-se mais em classificar tickets do que em corrigi-los.
Tamanho da implantação
Como corolário da frequência de implantação (veja acima), o tamanho da implantação – medido pelo número de pontos de história incluídos num build ou lançamento – pode ser usado para monitorar o tamanho do lote dentro de uma equipe específica.
Manter as implantações pequenas mostra que sua equipe está fazendo commits regularmente, com todos os benefícios que isso traz. No entanto, como as estimativas de histórias não são comparáveis entre equipes de desenvolvimento, essa métrica não deve ser usada para medir o tamanho geral da implantação.
Conclusão
O monitoramento dessas métricas permite entender melhor o desempenho do pipeline de CI/CD e se você está em uma tendência de alta ou de baixa.
Você pode usar métricas para identificar áreas de seu processo que merecem mais atenção. Depois de fazer uma alteração, é uma boa prática continuar monitorando as métricas relevantes para verificar se elas tiveram o efeito desejado.
No entanto, embora as métricas possam fornecer indicadores úteis de desempenho, é importante ler os números no contexto e considerar quais comportamentos podem ser incentivados ao se concentrar em uma determinada métrica. Lembre-se de que o objetivo não são os números em si, mas manter seu pipeline rápido e confiável para que você possa continuar entregando valor aos usuários.