A Microsoft lançou uma versão preliminar do seu novo Guia de Branching e Merging. Apesar de ser destinado aos usuários do Team Foundation Server, muitos dos conselhos são aplicáveis a outras ferramentas de controle de versões. Começamos com a topologia básica apresentada. (Veja uma introdução conceitual às técnicas de branching e merging no MSDN).
Como na maioria dos guias de branching e merging, existe um branch principal que serve como origem para todos os demais branches. Conhecido por muitos como "tronco" (trunk), a Microsoft se refere a este branch como "principal" (main). Originados a partir do branch principal, existem outros dois branches importantes, conhecidos como "desenvolvimento" (development) e "entrega" (release).
As orientações iniciais para os branches de desenvolvimento não são estritas, uma vez que dependem da forma com que cada empresa organiza equipes e funcionalidades. Uma recomendação em especial foi mantida de versões anteriores do guia: a Microsoft continua defendendo a ideia de não incrementar os números da versão em branches de desenvolvimento. A teoria é que, se o número da versão for incrementado apenas no branch principal, é possível dizer, de imediato, quanto tempo se passou desde que o branch de desenvolvimento foi ressincronizado com seu branch principal.
Para os branches de entrega, a Microsoft oferece algumas opções. A mais simples é criar apenas um branch chamado literalmente de "entrega". A Microsoft tem este modelo como o seu "plano básico"; este faz sentido para os cenários de Continuous Deployment, em que há necessidade de se trabalhar simultaneamente em mais de uma versão ao mesmo tempo.
Se forem suportadas múltiplas versões de uma mesma aplicação, e estas versões forem atualizadas ocasionalmente através de service packs, então é recomendado o modelo que a Microsoft chama de "plano padrão". Neste plano um branch de service pack é criado para cada grande entrega. Ao mesmo tempo, o branch da entrega em si é criado a partir do seu respectivo branch de service pack e é marcado como "somente leitura". Uma vez que ele não pode mais ser alterado, o branch também é util para atender requisitos de conformidade e para manter um snapshot preciso de produção. A figura abaixo, extraída do guia da Microsoft, indica algumas possibilidades.
Quando necessário, hotfixes emergenciais podem ser aplicados diretamente ao branch de entrega e depois serem migrados de volta para o branch principal. Entretanto, se hotfixes ocorrem com frequência, pode ser aconselhável criar um branch separado especificamente para tratá-los. O Guia da Microsoft explica, na seção "Plano de Branch Avançado", como este branch adicional afetaria os fluxos de trabalho (veja também a figura abaixo).
A última estratégia discutida no guia da Microsoft, relacionada a branching para gerenciar entregas, é o "Plano de Promoção de Código" (veja a figura a seguir). Este plano foge da ideia de branches separados para desenvolvimento e entrega. Ao invés disso, os desenvolvedores trabalham exclusivamente no branch principal, enviando atualizações para o branch de testes sempre que sentirem que o código está suficientemente estável. Por fim, uma vez considerado pronto, o código no branch de testes é promovido para o branch de produção.
Embora exista uma diferença filosófica entre este e o Plano Básico, na medida em que se considera a execução dos planos não há, na prática, muita diferença.
O resto da seção "Plano de Branch Avançado" discute opções para lidar com branching com base em características (features). Neste caso, as técnicas que são apresentadas não funcionam igualmente bem com as estratégias para controle de entregas, como o Plano Básico e o Plano de Promoção de Código.
Workspaces locais e remotos
Muitas das queixas sobre o TFS vêm da sua necessidade de conexão permanente com o servidor. Mas existe uma boa razão para isso. O TFS foi modelado primariamente para lidar com os problemas de desenvolvimento da Microsoft, como:
- Bases de código muito grandes (mais de 5 milhões de arquivos por branch, com uma utilização média de 100 mil a 200 mil arquivos por desenvolvedor)
- Equipes de desenvolvimento distribuídas globalmente e com conexões relativamente lentas (300 kbps ou menos)
Claramente, o TFS é superior a um sistema de controle de versões descentralizado, quando se precisa criar um branch que contém 5 milhões de arquivos. Isso porque tentar baixar o histórico de alterações para tantos arquivos através de cada branch não é factível.
Porém a maioria das equipes de desenvolvimento não trabalha desta forma. Mesmo o kernel do Linux possui apenas por volta de 10 milhões de linhas de código e a maioria dos projetos não chega perto desse número.
O TFS 11 permite uma maneira diferente de trabalhar ao introduzir os Workspaces Locais. Também conhecido como "estilo Subversion", este modo de funcionamento local atende a muitas das queixas de desenvolvedores em relação ao TFS:
- Os arquivos não são somente-leitura, podendo ser editados à vontade. Sempre que editados, os arquivos são detectados automaticamente como "checked out";
- Se arquivos novos são criados, o TFS irá detectá-los e permitir ao desenvlvedor adicioná-los ao projeto;
- Se arquivos forem excluídos localmente, o TFS irá detectar e apresentar a opção de excluí-los remotamente, ou restaurar a cópia local a partir do servidor;
- Uma das consequências mais interessantes é que não é mais necessário utilizar uma ferramenta integrada ao sistema de controle de versões para que as coisas funcionem bem. Devido ao sistema de arquivos ser o ponto de controle, é possível usar até mesmo o Notepad (ou qualquer outra ferramenta similar), que o TFS funcionará da maneira esperada. A cópia local se torna a principal e o Team Foundation Server sincroniza as mudanças da maneira apropriada.
Note que, para aqueles que preferem um fluxo de trabalho no estilo de sistema de controle de versões distribuído (ex.: git) será necessário aguardar pelo TFS 12.
Gerenciamento de Recursos Compartilhados no Team Foundation Server
A seção final do do guia trata das opções para gerenciamento de recursos compartilhados. Com o Visal SourceSafe, recursos compartilhados eram fáceis de lidar. Era possível simplesmente criar vínculos entre diretórios de forma que "$\projects-a\bin\commons" e "$\commons" fossem o mesmo diretório. E, caso necessário, um único comando poderia quebrar este relacionamento.
O TFS não possui essa capacidade, então, ao invés disso, é preciso escolher uma das seguintes opções:
- Duplicar os arquivos compartilhados em cada branch. Isto fornece isolamento à custa do espaço em disco desperdiçado;
- Manter um diretório compartilhado separado fora dos branches. Este diretório é referênciado no projeto através de paths sugeridos, uma técnica muito suscetível a erros e que funciona apenas para assemblies do .Net;
- Usar mapeamento de workspaces para fazer o diretório compartilhado parecer estar dentro de cada branch no disco local. Esta opção é mais versátil do que a de paths sugeridos, mas requer que todos os desenvolvedores configurem os mesmos mapeamentos.
As vantagens, desvantagens e fluxos de trabalho para cada uma dessas opções são detalhados no guia.
Conclusões
É importante destacar que as recomendações apresentadas no guia estão sendo desenvolvidas de forma colaborativa. A Microsoft tem solicitado, ativamente, feedbacks pelo site CodePlex do Guia de Branching e Merging do TFS. Espera-se que dezenas de milhares de equipes de desenvolvimento leiam este guia. Se você não concordar com algum dos conselhos expostos, este é o momento de se manifestar.