Apresentando uma política de ramificação de controle de versão a uma equipe pequena

Sou um empreiteiro que começou recentemente com uma empresa.

A equipe é composta por 3 desenvolvedores, que consistem em 2 desenvolvedores de nível júnior a médio, com outro no mesmo nível começando em breve e eu (6 Anos xp). Para ambos os desenvolvedores existentes, é o primeiro trabalho fora da universidade / faculdade, e eles nunca tiveram um desenvolvedor sênior supervisionando seu trabalho antes.

Não há uma política explícita de controle de versão. Os desenvolvedores fazem todo o desenvolvimento no tronco e, em seguida, implantam na produção diretamente de suas máquinas de desenvolvimento. A equipe existente não está familiarizada com ramificações.

Estou mudando tudo isso e introduzindo CI, servidores de teste / preparo / produção de TDD, etc, juntamente com uma política de controle de versão para complementar isso.

O sistema de controle de origem é o TFS, que eu nunca usei antes. Está configurado como um repositório gigante.

Eu escrevi algumas dicas para eles, mas há algo mais que eu deva adicionar / alterar, tendo em mente a experiência da equipe?

Política de Controle de Versão

O desenvolvimento é feito no tronco

Se uma mudança for estimada em mais de uma semana, ela deve ser feita em uma ramificação, com mesclagens regulares do tronco na ramificação para impedir que os dois fiquem fora de sincronia.

Liberar ramificações criadas para o código de produção. Esse ramo deve conter apenas código estável. Podemos ter um ramo de lançamento que é atualizado a partir do tronco uma vez por sprint, ou podemos fazer um ramo de lançamento separado para cada semana.

Se uma correção de bug urgente que afeta o código de produção precisar ser feita, ela será feita na ramificação de lançamento e mesclada novamente no tronco.

Se adotarmos a estratégia de ramificação de uma liberação, o tronco será mesclado na ramificação de liberação uma vez por sprint no final do sprint.

Se adotarmos a estratégia de ramificação separada por liberação, o tronco NUNCA será mesclado na ramificação de liberação

Em alguns cenários, pode ser necessário corrigir o bug duas vezes em ramificações diferentes, se as ramificações divergirem demais. Se estamos fazendo sprints curtos, isso não deve acontecer com muita frequência.

Eu pretendo ter três servidores. Ambiente de teste que está sempre executando o código mais recente no repositório. Um ambiente de temporariedade que está executando o candidato à versão mais recente para preparar / testar o código do Release Candidate e para fins de UAT e o ambiente de produção.

A razão pela qual pretendo fazer isso é que, até agora, o cliente fez apenas software interno. O mais novo projeto é para um cliente de mídia de alto perfil, e sinto que a equipe precisa adotar um modelo de desenvolvimento mais profissional do que o que faz no momento.

Por exemplo, no momento, um usuário pode telefonar para a equipe com um relatório de erro. Os desenvolvedores localizam e corrigem o erro, fazem um teste rápido do globo ocular em suas próprias máquinas e, em seguida, implantam diretamente na produção. Nenhum teste automatizado ou qualquer coisa.

Em retrospectiva, acho que o ramo de recursos é um passo longe demais e eu removerei isso.

Então, basicamente, tudo se resume a: a) nenhuma ramificação; b) uma ramificação de liberação e o tronco; ec) uma ramificação de liberação por liberação e o tronco.

Eu estava inclinado para o último. Meu pensamento inicial seria que eu teria um candidato a lançamento e um lançamento para estar ao vivo em servidores separados (UAT / Produção) ao mesmo tempo, mas efetivamente o tronco é o candidato a lançamento a qualquer momento, portanto, uma filial por liberação está inclinada para a loucura. Meu único pensamento seria se não quiséssemos que nossas partes interessadas vissem o código de desenvolvimento, talvez precisássemos de um ramo candidato a lançamento separado, mas o YAGNI e tudo mais .....

Para uma equipe de 3-4 desenvolvedores, você está propondo MUITAS ramificações.

Cada filial que você cria é uma sobrecarga adicional que vem com um custo (tempo gasto na fusão, mantendo o controle de onde está, etc.). Você precisa ter certeza de que o benefício que obtém de uma filial supera o custo.

Lembre-se de que o único benefício real de uma ramificação é o isolamento de código. Isso significa que você precisa de um motivo concreto para querer ter o código isolado.

Ter uma ramificação de liberação separada para cada sprint é insano. Por que você precisa do código de um sprint isolado do código para o próximo? Por que não apenas ter um único ramo de liberação estável que é transportado a cada sprint?

Se uma mudança for estimada em mais de uma semana, ela deve ser feita em uma ramificação, com mesclagens regulares do tronco na ramificação para impedir que os dois fiquem fora de sincronia.

Quase qualquer novo recurso não trivial levará pelo menos uma semana em tempo real depois de você considerar o desenvolvimento, os testes do desenvolvedor, as interrupções diárias e outras atividades, etc.

Além disso, o que é uma "mesclagem regular"? Diariamente? Semanal? Cada mesclagem leva tempo - você precisa garantir que o ramo de mesclagem de destino seja construído e executado após as alterações. Em uma equipe pequena, a mesclagem frequente é uma sobrecarga.

Temos uma equipe de 4 desenvolvedores trabalhando em mais de 1 milhão de linhas de código e é assim que operamos:

• Ramo principal onde todo o desenvolvimento é feito
• Uma ramificação por versão principal (feita aproximadamente uma vez por ano)

A única regra principal é: não faça o check-in do código que não cria.

É isso aí. Simples, fácil de entender, obtém o isolamento de que precisamos (a qualquer momento, podemos criar uma versão compilada para qualquer versão).

As vantagens de ter todo o trabalho de desenvolvimento realizado em um único ramo:

1. Os desenvolvedores estão sempre sincronizados entre si. Nenhuma fusão dolorosa porque dois desenvolvedores estavam em suas próprias ramificações por semanas criando alterações incompatíveis.
2. Construções quebradas são encontradas no mesmo dia. Temos uma compilação noturna que executa o código mais recente no main. Se alguém fizer check-in de código que não é compilado por algum motivo, saberemos imediatamente.
3. Com todo mundo sempre trabalhando no mesmo código, aumenta as chances de um bug ser encontrado mais cedo ou mais tarde.
4. Nenhuma sobrecarga de mesclagem além das correções direcionadas para liberar ramificações. Em uma equipe pequena, essa é a grande.

Você escreveu algumas dicas para eles, mas não explicou por que sua abordagem é melhor do que a que eles já usam . Isso pode ser problemático. Se você estiver com o espírito "Vamos fazer do meu jeito, porque eu tenho seis anos de experiência profissional e você não" (e lendo sua pergunta, parece exatamente dessa maneira), esteja pronto para ser odiado por os membros de sua equipe que tentarão fazer o que puderem para não aplicar seus conceitos.

Eles têm um problema que precisa ser resolvido? É crucial responder a essa pergunta primeiro, porque eles realmente têm um problema e aceitam suas sugestões, ou estão funcionando perfeitamente como estão atualmente, e você está apenas pressionando o seu modo de trabalhar , apenas porque prefere trabalhe dessa maneira.

Eventualmente, forçá-los a usar ramificações pode ter um impacto extremamente negativo . Trabalhar com um tronco é fácil, especialmente em ambiente Agile. Um desenvolvedor confirma alterações no tronco, lidando com pequenos conflitos e essas alterações são imediatamente usadas pela plataforma de Integração Contínua. Com galhos:

• Um desenvolvedor precisa pensar onde a mudança deve estar localizada,

• Alguém tem que gerenciar ramificações e mescla ramificações para o tronco,

• Mesclagens entre ramificações são feitas com menos frequência do que confirmações, o que significa que alguém precisa lidar com conflitos maiores e mais difíceis de lidar do que um conflito entre duas confirmações,

• Todo commit não encontra necessariamente seu caminho para a Integração Contínua, o que atrasa as informações que os desenvolvedores obtêm sobre os efeitos que um commit pode ter (especialmente regressões).

O fato de que:

A equipe existente não está familiarizada com ramificação

torna as coisas ainda piores. Eu trabalhei em uma equipe de programadores inexperientes, onde um gerente inexperiente decidiu brincar com filiais. Isso resultou em muito ( muito ) tempo perdido e é exatamente o que você deseja evitar para um projeto que tem prazos.

Como Mainma diz, tenha cuidado com a ramificação. Você menciona ramificações a cada poucas semanas, é realmente necessário ter muitos ramos?

Como alternativa, você também pode ter um modelo 'pull' em vez de um modelo push. Se você estivesse usando Git ou Mercurial, poderia ter um servidor de integração para validar suas alterações antes de enviar para o servidor central. No TFS, você pode fazer algo semelhante usando check-ins fechados . Dessa forma, você pode ter validação e evitar a complexidade das ramificações.