Boa tarde pessoal, primeiro gostaria de agradecer à todos pela presença no evento e na minha palestra! Estou aqui através desse post publicando a minha palestra (que pode ser baixada aqui) e gostaria de complementar alguns tópicos que infelizmente não deu tempo de compartilhar com vocês, por isso vamos ao que interessa!

Primeiro é onde vocês podem baixar  o Branch Guide dos ALM Rangers.

Nesse link ( Projetos dos ALM Rangers ), você pode encontrar todos os projetos que estão sendo desenvolvidos pela equipe, vale a pena dar uma olhada em tudo que estamos trabalhando e qualquer proposta nova ou problema encontrado não deixe de nos comunicar!

Mas especificamente sobre a minha palestra, segue o endereço do Visual Studio Team Foundation Server Branching and Merging Guide .

Outros pontos que não deram tempo de passar na palestra:

Melhores Práticas

• Usar nomes significativos para o Branch – Sempre que possível utilize nomes que realmente tenham algum siginifcado para o seu projeto. Isso parece um detalhe bobo, mas imagine a situação onde você está utilizando a estratégia por feature, e começa utilizando nomes não tão significantes. Com o andar do projeto, esse número de branches pode ficar alto e sem nomes significativos, pode começar a gerar problemas para a sua equipe, impossibilitando que ela saiba qual feature eles tem que trabalhar no momento.

• Sempre prefira Branch ao invés de code-freezen – Code-freezen é um dos ” porquês “ que queremos evitar. Então sempre que surgir uma situação onde a sua equipe de desenvolvimento tiver que ficar parada para que testes, deploys ou qualquer outra coisa que não seja desenvolver novos códigos, acertar bugs identificados em versões anteriores, pense em criar um branch. Isso já gera um valor para esse branch justificando a sua criação.

• Integre sempre que possível – Integrar sempre que possível tem que ser um mantra! deixar para fazer tudo na última hora, trazer as modificações geradas na main para o seu branch de trabalho apenas no final, pode gerar um tempo muito maior de resolução de conflitos e com isso impactar diretamente no seu prazo de entrega. Por isso, integre sempre, pelo menos 1 vez por semana, mais do que isso, você e sua equipe já estarão correndo riscos.

• Resolva conflitos no “Soft” branch – O Soft branch é onde você está desenvolvendo no momento, é o seu branch de desenvolvimento. Sempre resolva os comflitos nesse branch e nunca no que é considerado o mais estável, como o Main por exemplo. Isso que dizer que você antes de publicar alguma nova feature para a Main, baixa a versão do Main para a seu Branch de desenvolvimento resolva todos os conflitos e aí sim, faça a entrega para o Main.

• Evitar branches em cascatas – Tente evitar ao máximo o cascateamento nos branches, pois isso torna muito mais complicada a sua integração e trás um tempo muito maior para a liberação do seu código. Como vimos no início da palestra, isso vai impactar diretamente no custo de manutenção do branch, o que pode não trazer o valor esperado para o branch exigindo que a sua estratégia tenha que ser completamente revista.

• Isole a mudança – Isolar a mudança e não a equipe. Nós temos que isolar apenas  o que queremos modificar no nosso sistema sem impactar os outros membros do time e nunca isolar um grupo ou uma pessoa. Todos tem que saber o que está acontecendo no sistema e porque algum branch foi criado. Caso você comece a isolar as pessoas, você começará a criar silos na sua equipe o que trará muitos problemas para o seu projeto. TOME MUITO CUIDADO!

• Evitar Baseless Merge  – Como vimos, as vezes o Baseless Merge é necessário (Estratégia de Branch por Release com Mainline), mas tome cuidado com essa técnica, pois ela acaba abrindo caminhos novos caminhos para a release do seu sistema que podem forçar o seu código a não passar por áreas críticas e ser lançada uma versão sem todas as funcionalidades ou bugs que já foram corrigidos.

Anti-Padrões

• Merge Paranoia – Medo de realizar o merge entre dois branches. Se isso está acontecendo com o seu projeto, com certeza sua estratégia de branch não é a mais adequada para o seu problema. Pare agora e revise sua estratégia. Esse medo de realizar merges entre branches não pode existir.

• Merge Mania – Ao contrário da primeira, realizar merge todo o tempo também não é uma coisa boa. Esse item também sugere que a estratégia selecionada não está sendo a mais eficaz nesse momento para o seu projeto. Para um tempo e revise o seu modelo.

• Big Bang Merge – Deixar para fazer o merge apenas na última hora, na hora de realizar a liberação do código para Release. NUNCA FAÇA ISSO!

• Branch Mania – Um dos pontos para que um branch seja criado é descobrir qual o valor que ele trará para o projeto. Se ele não trouxer valor ou tiver alguma outra técnica que possa ser empregada no lugar, então não crie o branch! Cada branch que você criar, é mais uma complexidade que você está trazendo para a gestão do seu sistema. Por tanto, sair criando branches sem um bom motivo também é um problema.

• Branches Temporarios – Nunca crie branches para executar algum teste ou fazer pequenas alterações temporárias! Isso não trás valor para o seu projeto! para realizar esse tipo de tarefa, prefira usar shelve, com certeza ele vai resolver o seu problema e não trará complexidade desnecessária para o seu gerenciamento.

Escolhendo a sua estratégia

Esse não é um modelo único, porém é um ponto de partida para que você escolha qual estratégia de branch deve ser utilizada no seu projeto.

Utilize isso como um ponto de partida, mas adicione mais alguns pontos de validação para a sua decisão. Uma delas é, qual caminho que eu teria que percorrer para fazer a liberação do meu código ? Existe alguma compliance que eu devo seguir na minha empresa ? As vezes, como vimos na DEMO, teremos que utilizar mais de uma estratégia para atingir os objetivos que aquele projeto necessita.

Tenha em mente que cada projeto pode ter uma estratégia de branch diferente. Então sugiro que você tenha pelo menos 3 modelos padrões na sua empresa para projetos pequenos, projetos médios e um para projetos grandes ou críticos. Mas na hora de definir, faça uma simulação para validar se aquela estratégia não vai lhe trazer complexidade desnecessária.

Espero que tenham gostado da palestra e em caso de dúvidas, deixem seus comentários ou enviem por twitter ou e-mail.

Até a próxima!

Claudio Leite

Claudio Leite é consultor de ALM da Lambda3, Visual Studio ALM Ranger, PSD, PSM I e PSM II. Graduado em Ciência da Computação pela Universidade Católica de Petrópolis, MBA e POS-MBA em Gestão de Projetos pela Fundação Getúlio Vargas. Twitter: @claudiobernardo