Sempre efetuar o desenvolvimento na trunk pode ser um grande desafio onde times não estão habituados a fazerem commits regulares. Porém, este tipo de pratica traz diversos beneficios:
- Garante que todo o código é continuamente integrado;
- Desenvolvedores recebem as atualizações de outros desenvolvedores imediatamente, desta forma, novas atualizações são testadas por outros desenvolvedores;
- Evita problemas de merges e integração no final da vida das branches.
Branches (entende-se por branches de longa duração) deveriam somente ser criadas quando não há a necessidade de merge na trunk, por exemplo branches para liberação de versões.
Como gerenciar times grandes com diversos releases se comites são realizados na trunk? A reposta é uma boa componentização, desenvolvimento incremental e, ocultamento de funcionalidades. Para tal, há necessidade de maior cuidado na arquitetura e desenvolvimento, mas os beneficios de não ter períodos longos e imprevisiveis de integração, onde o trabalho para merge de multiplas branches para se criar um release viavel, é muito maior que o esforço.
A criação de uma branche para alterações complexas de forma que outros desenvolvedores não sejam impactados parece ser a solução mais simples, porém, na pratica leva a branches de longa duração, a qual, divergem bastante da trunk. O processo de merge acaba se tornando complexo e levando uma quantidade de tempo não previsivel. Cada novo merge também pode afetar outras parte do sistema, criando-se assim um processo de estabilização. Desta forma, releases levam mais tempo do que esperado, possuem um escopo menor e a qualidade é menor do que o esperado.
Seguindo esta direção, rapidamente o código se tornará não manutenivel, o que tornará dificil a inclusão de novas funcionalidades, correção de bugs e refatorações.
Branches de longa duração anulam todos os beneficioes e problemas que a integração continua se propõem a resolver. Comite sempre na trunk, ao menos uma vez ao dia. Raras serão as situações onde este caminho não funcionará e sempre existem soluções para mitigar os problemas encontrados.
Criação de branches para releases são aceitaveis porque o desenvolvimento de novas funcionalidades é feito na trunk, assim bugs encontrados são corrigidos na branch e mergeados na trunk.
É importante que não sejam geradas novas brunches a partir de uma branche de release, porque estas branches deveriam ser utilizadas somente para correção de bugs e não o desenvolvimento de novas funcionalidades.
Este modelo baseia-se na criação de uma camada de abstração entre a implementação atual e a nova a ser desenvolvida.
Seu uso é recomendado em casos onde alterações grandes e/ou de grande impacto serão efetuadas. Quando concluidas, a implementação antiga pode ser removida ou habilitada. Alterações grandes e/ou complexas, podem não ser viáveis através de comites incrementais, para tal, uso de camadas de abstração é uma solução viavel:
- Crie uma camada de abstração;
- Refatore o sistema para usar esta camada;
- Desenvolva a nova implementação;
- Reaponte a camada de abstração para utilizar a nova implementação;
- Remova a antiga implementação se necessário;
- Remova a camada de abstração se necessário.
Esta é uma alternativa ao uso de branches em alterações complexas, permite que os desenvolvedores continuem trabalhando e alterando grandes trechos de codigo enquanto comitam na trunk, dessa forma, beneficiando-se das vantagens da integração continua. A decisão de qual implementação utilizar é definida por configuração, que pode ser alterando durante deploy ou mesmo em runtime.
Este também é um excelente modelo para transformar um sistema monolitico em modular. Separe o trecho de código que deseja modularizar e o reescreva.
A parte mais complexa é econtrar os pontos de entrada e gerenciar quaisquer mudanças necessárias para isola-los, entretanto esta é uma tarefa mais simples do que realiza-la através de uma branche. As vezes esta pode ser uma tarefa muito complexa, onde a criação de uma branche para isolar os trechos seja necessário, após concluido, o uso de branche por abstração pode ser utilizado para o restante do trabalho.
É importante reforçar o uso do desenvolvimento somente em trunk, esta é uma boa pratica, que se aplicada corretamente traz diversos beneficios, como maior qualidade de código e força o uso de uma boa arquitetura.