Relaxa que é inevitável: Branch, Trunk, Tags e Merges

Com frequência me perguntam em meio a um treinamento ágil, como métodos ágeis resolvem a complexidade do versionamento de fontes … a resposta é simples, a auto-organização, comunicação e ciclos curtos de feedback, mitigam os riscos inerentes ao versionamento, branchs e trunks, eventuais tags e frequentes merges, mas não porque propõem técnicas revolucionárias, mas porque gera maior domínio do processo e da solução.

Algumas empresas usam esta terminologia e pastas de forma diferente, as vezes invertidas, desde já peço licença, porque aprendi com o melhor e a seguir relato como praticamos há uma década. Igual, aos que interpretam invertido o conceito de Branch e Trunk, ok, o que importa é o conceito, o como e a nomenclatura ficam ao gosto do freguês. Já trabalhei com equipes que usavam GIT, SVN, ClearCase (IBM), SourceSafe e TFS (MS), entre outras ferramentas.

Em um exemplo disponível na wikipedia, uma única versão Trunk evoluindo entre os momentos 1 a 14 (verdes), estes simbolizam publicações em produção, enquanto tivemos Branchs iniciando talvez evolutivas ou corretivas em 2, 6, 7 e 11 (laranjas), que levadas a bom termo geraram publicações em produção e atualizações do Trunk simbolizadas por 4, 10 e 12. As Tags são cópias a partir de Trunk, como 5, 13 e 16 (azuis), por questões de preservação histórica ou segurança, tratados como simples backups. É possível perceber um abandono de trabalho, a partir do 11 prosseguiu até 15, backupeado em 16 e abandonado.

Para quem usa Git, um mapa mais preciso, proposto pelo Eduardo Namba, uma ferramenta de versionamento cada vez mais conhecida, difundida e utilizada. Nela, vemos mecanismos mais sofisticados baseados em uma ferramenta mais adequada para a complexidade de nossas equipes e projetos. O Trunk como Master e Branches como Develop, permitindo outras oportunidades com Releases e Features:

Trunk = Fontes da última publicação em produção

TRUNK é a versão corrente em produção, um continuum atualizado a cada publicação liberada para o usuário. Uma trilha imprescindível, pois na eventualidade de um ocorrência urgente em produção, precisamos ter preservada uma versão exatamente como o sistema está em produção. Se necessário realizar uma correção em produção, tenho a garantia de que ao baixar meu Trunk e corrigir, posso publicar com segurança e integridade.

Há somente um Trunk, nunca mais de um, pois deve sempre ser um espelho dos fontes que estão neste exato momento em produção, a serventia dele restringesse a isto, ser uma versão exatamente igual a que está em produção, independente de quantas equipes estão trabalhando em evolutivas e corretivas. Qualquer alteração em curso NUNCA estará refletida no TRUNK antes desta já ter sido publicada em produção.

Branch = Versões ainda em desenvolvimento e testes!

Ao iniciar um novo ciclo ou projeto, evolutivo ou corretivo, é preciso discutir e decidir sobre a geração de um Branch ou a continuação de um que está ainda em curso. Apenas após desenvolvido, testado e homologado em um Branch, exigindo assim a decisão sobre a publicação de todo o pacote nele em curso ou até mesmo a criação de um novo Branch a partir de nosso Trunk, merges e só então publicação e atualização do Trunk.

Parece complexo … e é mesmo, é preciso ter atenção constante, com frequência há um profissional mais senior ou mesmo uma equipe responsável pelos merges e preparação final da versão que vai entrar em produção. Concomitantemente a tudo isso temos toda a construção e consolidação também da gestão de configuração, diferentes ambientes envolvidos, frequentemente três (dev, tst e prod), podendo atingir cinco ou mais (dev, tst, hml, pré-prod e prod).

Branch é o nosso dia-a-dia, é em um Branch que o desenvolvimento transcorre até que tenhamos uma publicação em produção, convertamos os fontes daquele Branch em Trunk e a partir de então começa um novo ciclo de desenvolvimento, sempre em um Branch. A importância é preservar as negociações e decisões consistentes com aquilo que entra em produção e lhe garante menutenabilidade. O risco existe e significa falhas, gaps ou surpresas inesperadas em  produção.

Tag = Um backup preservando certo momento histórico!

Tanto um Branch ou Trunk pode ser preservado através da criação de uma Tag, como se fosse um backup histórico, um momento específico da evolução do produto que queiramos ou precisemos ver congelada no tempo. As Tags não existem para serem alteradas ou mantidas, esta deveria ser prerrogativas de um Branch, a função da Tag é mais para preservação, se necessário podemos gerar um Branch a partir de uma Tag, da mesma forma que fazemos a partir do Trunk.

Descontrole gera surpresas desagradáveis em produção!

Independente da metodologia, esta é uma disciplina fundamental para garantir estabilidade e integridade na evolução do produto que estamos desenvolvendo. Descuidos ou falhas de comunicação com frequência geram tensão e urgências, como pacotes emergenciais e riscos desnecessários. Já vi casos em que o cliente liga dizendo que certa correção ou funcionalidade disponibilizada no pacote anterior desapareceu após a publicação do seguinte … decorrente de uma falha em merge ou descontrole entre Branchs.

Um problema mitigado pelas metodologias ágeis, comunicação frequente, ciclos curtos de feedback, colaboração e senso de time, mas parar no meio um Branch por perda de prioridade sempre gera retrabalho e com frequência desperdícios que podem chegar ao descarte do que havia sido feito. Parar no meio ou congelar uma versão pronta mas não aprovada de um Branch obriga o time a abrir um novo Branch e precisará muito controle para retomar o que havia sido congelado.

Diferentes Branchs, mesmo quando absolutamente necessários, agregam riscos e aumentam o trabalho necessário de merge, rastreabilidade e segurança para nossos clientes, que devem estar cientes e contar com nosso apoio especializado quanto a estratégia, riscos e oportunidades relacionadas a cada mudança repentina ou “inevitável”, pois muitas vezes estas decisões não levam em consideração estes riscos, pois possuem um custo x benefício.

Scrum, Kanban ou ScrumBan

A cada iteração, a cada planejamento ou design de uma feature, história ou demanda é preciso acordar esta questão, pois é preciso que toda a equipe permanentemente mantenha atenção frente a esta disciplina. Não só o Branch, Trunk e eventualmente a necessidade de uma Tag, mas frente ao desafio de paralelizar ou não o trabalho, de forma a termos um Lead Time médio baixo, entregando o mais breve possível cada história prioritária.

Algumas equipes me pedem uma receita ágil mágica para que este versionamento não gere esforço ou mesmo riscos, mas não há, a solução real é planejamento, comunicação, desenho colaborativo da solução e execução. Nada que os dois principais frameworks já não privilegiem, separados ou juntos, Scrum e Kanban proporcionam a equipes ágeis menor risco de surpresas infelizes na entrada em produção.

Múltiplas equipes ou equipes distribuídas

A decisão quanto a diferentes equipes de um mesmo projeto abrirem um único Branch ou mais de um, quem ou como será consolidado os merges, mediante testes, homologação e estruturação final de pacotes com o cliente para entrada em produção … envolve tecnologia, complexidade, perfil das equipes e empresa, experiência, etc.

Sob um mindset ágil, a cada passo, planejamento de sprint, scrum de scrum, retrospectiva, é preciso levar esta estratégia a bom termo e aprender com as experiências, acertos e erros. Usualmente, temos um arquiteto ou profissional mais senior que fica responsável por orientar ou executar. As vezes não há uma orientação explicita aos times, mas sempre haverá alguém com experiência que se torna referência ou tornando-se formador de opinião.

GC, modelo SECI e melhoria contínua

A implantação de modelos eficazes para gestão do conhecimento, tácito e explícitos, mantendo lições aprendidas e padrões estabelecidos de forma clara e transparente é o melhor caminho. Um erro frequente em empresas de todos os portes é não terem um kit de entrada para novos integrantes, para muitas empresas ainda é puro improviso a inserção de um novo integrante ou início de um novo projeto … um eterno inicio do quase zero, onde o aprendizado se perde nos meandros e idiossincrasias do cotidiano … mas um dia a gente chega lá!

O principal em todo este esquma, seja como for que sua empresa ou equipe o pratique, é estabelecer mecanismos de aprendizado e gestão do conhecimento, definição de boas práticas recomendadas ou mesmo padrões a serem seguidos. Versionamento não é fácil, mas não tem porque ser tão difícil, pois trata-se de uma disciplina necessária e inevitável, conscientizar-se disto é o primeiro passo.

Dei uma navegada e recomendo a leitura descontraída disponível na wikipedia em português, recheada de exemplos, modelos, recomendações e glossário – https://pt.wikipedia.org/wiki/Sistema_de_controle_de_vers%C3%A3o