Quantas vezes você faz deploy por dia? É isso mesmo que você leu: “Por dia”! E desses deploys, qual a porcentagem de introdução de falhas? No artigo de hoje vamos discutir o que é Deploy Frequency (DF) e Change Failure Rate (CFR) e a sua importância para engenharia de software.
O que é Deploy Frequency?
A dica está no nome. Literalmente é a frequência com a qual você faz deploy de novas versões da sua aplicação, dentro de um determinado período. Pela sua natureza, é muito fácil inferir que o Deploy Frequency está intimamente ligado às métricas de velocidade do time. Logo, toda ação que impacte nas métricas de Cycle Time, Time To Market e etc, pode influenciar diretamente no índice percebido pelo Deploy Frequency.
Contudo, as métricas de velocidade, sozinhas, não tem esse poder. Afinal, você poderia aumentar o seu throughput, tendo entregáveis prontos mais rapidamente, mas aguardar o “pacote de entregas” atingir um certo tamanho. Esta espera, com certeza, irá diminuir o indicador de Deploy Frequency.
A pergunta que a métrica Deploy Frequency faz para nós é: “Se está pronto, porque não entregar logo?”. Esta simples pergunta vem questionar a base dos nossos processos de desenvolvimento. Afinal, ter todo um conjunto de cerimônias em torno do deploy, juntando tudo para ser entregue no final da sprint, é o preconizado pela maior parte dos frameworks de gestão. Entretanto, essa pode vir a ser uma má prática: A entrega de grandes pacotes de mudança.
Porque Deploy Frequency é contra grandes pacotes de entrega?
O maior problema com o tamanho das entregas está intimamente ligado aos bugs que ela pode gerar. É óbvio que nenhum time deseja entregar bugs. Inclusive adotamos uma série de processos de qualidade, cujo objetivo é evitar esse cenário. Mas o caso é que eles, os bugs, acontecem. E precisamos estar prontos para eles. Mas de que bugs estamos falando?
Pense em um pacote que entrega quatro features diferentes. Cada uma delas inclui uma alteração na estrutura de dados. Após o delivery, o sistema começou a gerar relatórios com falha e algumas exceções começaram a pipocar na tela do usuário. Qual foi a feature que, de fato, introduziu a falha? Perceba também que, para oferecer uma resposta rápida, você vai ter que desfazer quatro features e seus efeitos colaterais. Agora me responda: O quão dolorida e arriscada pode ser essa tarefa? Ela seria mais simples se fosse apenas uma feature?
Você até pode argumentar que existem formas de diminuir os problemas causados por falhas em migrations (como as non-destructive migrations). Mas não há dúvidas quanto a simplicidade da atuação quando falamos de um pacote de mudanças menor. O impacto desse pacote sobre a solução em produção é reduzido, melhorando o tempo de resposta. Assim, quanto maior o número de entregas diário, menor será o tempo de deploy e o tempo de resposta a falhas.
Deploy Frequency é a favor das entregas contínuas
A esta altura você deve estar questionando todo o seu modo de trabalho. Talvez Kanban seja o mais indicado para esse processo? Talvez, ao invés de utilizar o Git Flow Workflow, seja melhor trabalhar com Trunk Based? Todas as medidas que te encaminhem para a entrega contínua, com certeza, vão te ajudar a ter um indicador de Deploy Frequency saudável. Mas existe um preço a ser pago.
Para adotar um modelo de entregas contínuas, não basta apenas que você possua pipelines que automatizem o processo de entrega, sem nenhuma intervenção humana. A pirâmide de testes fica muito mais importante. Mais do que testes de unidade, os testes de integração, testes de contrato, testes de interface tornam-se imprescindíveis. E tê-los prontos antes da entrega do código, pode estabelecer a diferença entre um deploy com sucesso ou falha.
Como você pode estar percebendo, Deploy Frequency é muito mais do que apenas contar quantas entregas você está fazendo. É um índice que vem questionar a base do seu modelo de trabalho, além dos benefícios claros envolvendo a entrega. Mas ele sozinho não ajuda muito. Afinal, você pode estar fazendo 4 entregas por dia, mas 3 delas geram erro. Por isso o Deploy Frequency tem uma contra-medida importante: Change Failure Rate.
O que é o Change Failure Rate?
Não basta apenas entregar. Precisa entregar e com qualidade. Change Failure Rate vem ser um contrapeso ao Deploy Frequency, uma vez que ele estabelece uma porcentagem de falhas frente a quantidade de deploys.
O CFR considera falha qualquer indisponibilidade durante o processo de deploy (algum serviço que esteja fora do ar, por exemplo), falha no processo de startup da nova versão do sistema, falhas durante a aplicação de migrations e qualquer bug introduzido que cause indisponibilidade do sistema ou que necessite de um hotfix na aplicação.
Quando o produto tem um Change Failure Rate (CFR) alto, é preciso analisar as causas envolvidas nessa falha. Em posse dessa análise, o time tem uma visão mais acurada de onde concentrar a atuação para melhoria. Quer seja na infra, quer seja nos testes ou nos processos.
Como calcular o Deploy Frequency?
A sua fórmula de cálculo é extremamente simples: Você precisa calcular a razão entre a quantidade de dias em um determinado período e a quantidade de deploys feitos nesse mesmo período. Digamos que você fez oito deploys (QD) no período (P) de um mês (30 dias, para facilitar). Assim temos:
DF = QD / P
DF = 8 / 30
DF = 0.26Nesse caso, o indicador está acusando que você está entregando, diariamente, 0.26 deploys.
Como calcular o Change Failure Rate?
A fórmula de cálculo do Change Failure Rate é igualmente simples. Basta estabelecer a razão entre a quantidade de Deploys com falha (F) e a quantidade de deploys do período (QD). Aliás, é importante ressaltar que o período considerado no Deploy Frequency é o mesmo considerado aqui, no Change Failure Rate.
Digamos que, dos oito deploys do exemplo anterior, 2 foram com falhas. Logo temos:
CFR = (F / QD) * 100
CFR = (2 / 8) * 100
CFR = 25%Com esses números, temos que 25% das entregas, geraram algum tipo de falha. Atente-se que para o cálculo do Deploy Frequency consideramos todo e qualquer deploy, independente do sucesso ou falha dele. Já para o Change Failure Rate, consideramos apenas o percentual de falhas.
Como aumentar saudavelmente o meu Deploy Frequency?
Como dito antes, a chave principal está em revisar o processo de desenvolvimento. Logo, a primeira questão a ser considerada é: O meu processo atual está satisfatório paras as minhas necessidades? Talvez o seu ramo de atuação não exija números incrivelmente altos de DF. Quem vai dizer isso, com certeza, serão outros indicadores como o uNPS, o tempo de resposta aos bugs encontrados, a taxa de retrabalho e assim por diante.
Outro trabalho importante é estabelecer um critério de valor. Se o seu processo está bom, qual seria a quantidade de entregas saudável pra esse processo? Se você tem um backend e um frontend e trabalha com sprint de 15 dias, talvez um bom começo seja de – no mínimo – oito entregas por mês.
Uma vez que essa métrica esteja do dashboard, é hora de correlaciona-la com outras. Por exemplo: O seu MTTR está alto e o DF está baixo? Será que a causa é o tamanho dos pacotes de entrega? O MTBF está baixo e CFR está alto? Pode ser que os seus processos de qualidade não estão sendo efetivos, causando instabilidade na solução. O Lead Time ou o Time To Market estão altos? Talvez este seja o momento de rever os seus processos e tentar alcançar um número maior de deploys.