Todos nós já ouvimos um desenvolvedor dizer “Prefiro fazer uma branch separada, será mais eficiente”. Difícil de recusar sem contra-argumentos. 

Podemos ter tido o mesmo tipo de pensamento que este desenvolvedor ou para criar nossa estratégia de teste. Os problemas surgem a médio prazo quando tentamos integrar nossas mudanças em um sistema mais amplo e colaborativo.

A gestão dos ramos de desenvolvimento é um assunto que impacta a produtividade das equipas e, em última análise, a da empresa.

Este artigo traça um paralelo com o risco associado à multiplicação de branches em um repositório de software. Compartilhamos as perguntas que deve fazer para a sua branching strategy..

Pode se sentir bem (a curto prazo)

Procura o projeto no repositório, faz um clone, começa a desenvolver. 

Tudo corre maravilhosamente bem, até a compilação corre bem na primeira execução. Esta é a forma ideal de desenvolver as suas funcionalidades com total tranquilidade. Além disso, ninguém pede que faça commits regulares no repo.

Essas metas estão longe dos olhos, longe do coração, e isso é bom. Nem precisa (ainda) de se preocupar com as alterações feitas por outros membros da equipe. Por que, aliás, o foco é a nossa branch.

Dias e, então, algumas semanas passam, deixando tempo para ajustar o desenvolvimento e uma serie de testes locais. Isso também é preferível porque o ambiente do UAT costuma ser instável e sem dados de teste.

É muito bom de poder programar em silencio sem ter que coordenar transversalmente.

Alguém deve pagar a conta um dia ou o outro

O gestor do projeto volta das férias e pergunta se a funcionalidade poderá ser testada no dia seguinte no UAT. Responde “Sem problemas, até tive tempo para testar bem” ao lançar um push no repositório principal.

O tempo de carregamento parece anormalmente longo em seu Macbook M1 o mais recente. Estranho, certamente a hora de tomar um café. Quando volta, o tamanho do changelog e sua lista de conflitos difíceis de fazer scroll o deixa nervoso.

Vou passar as próximas horas tentando descobrir qual parte do código integrar, sem conseguir compilar, muito menos testar. No dia seguinte, apesar de seus melhores esforços, sua filial e seus recursos ainda não estão disponíveis.

Essa situação de priorizar demasiado o curto prazo ainda é vivida por muitas equipes. O assunto da colaboração multifuncional com base no código é amplamente subestimado.

Uma visão autocentrada local muitas vezes dói.

Esse tipo de perspectiva se reflete na citação inicial usando a 1ª pessoa: “Prefiro trabalhar sozinho”.

O system thinking defende uma visão holística de um sistema, promovendo impacto global além de apenas otimizações locais. Precisamos aplicar o mesmo raciocínio ao desenvolvimento de software e gerenciamento de branches.

O problema não é criar uma branch. Podemos o fazer para apoiar um processo de revisão, enquanto mantemos commits ou atualizações regulares. O perigo está no distanciamento de nossa branch do nosso projeto principal.

Enquanto humanos, é difícil integrar o impacto dos famosos delayed feedback loops. Mais estamos pessoalmente e emocionalmente envolvidos, menos conseguir antecepar o seu impacto futuro. Pense nas tentativas de dietas praticadas com um gelado olhando a última serie na televisão..

Portanto, podemos facilmente tomar decisões locais que acabam sendo caras a médio prazo. Quase podemos perder de vista o modelo de branching escolhido pela equipe.

Podemos fazer branches sem utilidade

Os modelos de gerenciamento de branches são interessantes para colocar em perspectiva várias práticas de mercado. Mas, como acontece com as pirâmides de testes, o contexto, o bom senso e a adaptação continuam a ser fundamentais para que um valor seja capturado.

Somos facilmente guiados por hábitos como a verificação intensiva de e-mails ou de notificações. Também podemos cair na mesma armadilha de gerenciar nossos branches, criando um branch para qualquer propósito e para qualquer uso: por funcionalidade, por release, por hotfix de cada release, parece não ter fim.

O nosso objetivo é selecionar um modelo de gestão de branches alinhado com o nosso modelo organizacional, cultura e repositório. Se dois modelos parecerem adequados, o mais simples deve ser escolhido para conter a complexidade. Essas etapas são essenciais para evitar que 10 branches fazem perder  10 horas por alteração de função para um desenvolvedor.

Sem entrar em detalhes, se o Git Flow for o modelo que escolheu, reserve um tempo para identificar os fatores que o orientam para essa escolha. Pode estar procrastinando o tratamento das root causes em sua cadeia de desenvolvimento.

Podemos faltar de coragem

A procrastinação é um mecanismo humano transmitido de gerações anteriores. Aqueles que conservaram sua energia sobreviveram mais amplamente aos ataques de leões e outras surpresas.

Assim como a falta de esporte é perigosa para nós, a procrastinação é perigosa para o software.

É fácil ter medo de integrar o nosso código regularmente. Será que a compilação passará? Vou bloquear meus colegas? Se eu enviar meus desenvolvimentos para o UAT, como posso testar com êxito sem ter conjuntos de dados e ferramentas disponíveis? Tantas questões de integração muitas vezes negligenciadas.

Existem práticas como feature flags, CI/CD com quality gates, ferramentas de automação, etc. Ainda é necessário garantir a sua implementação e alinhamento com os objetivos do sistema. Para mim, é aqui que chegamos ao Quality Engineering, que deve atuar de forma transversal e com impacto.

Para se inspirar, pode consultar este artigo que relata os investimentos e escolhas defendidos pelo Google ao longo dos anos para o desempenho de sua cadeia de software: How Googles Does Repo (upcoming).

O mínimo de branches em um sistema integrado

Centrado em uma experiência de desenvolvimento caricaturada, encontramos os elementos importantes a serem considerados na gestão das nossas branches.

Devemos escolher a solução mínima que suporte um ciclo rápido de iteração de nossas equipas. Isso significa de permitir a integração, deploy e teste em todos os ambientes. Precisamos criar um ecossistema que deixe pouco espaço para a procrastinação ou o desejo de trabalhar em silos.

Em uma nota pessoal, quanto mais complexo o sistema parece, mais perguntas precisamos nos fazer. O nosso trabalho é conter a complexidade para apoiar o desempenho de uma organização. Para isso, simplifique, realize commits regulares até a produção.

Não se esqueça dos features flags e de outros mecanismos de ativação progressiva, se não “it hurts”.