Quando as ramificações de desenvolvimento devem ser criadas?

Estamos mudando a equipe de nosso projeto do uso de uma única ramificação Principal / Tronco para várias ramificações de Desenvolvimento / Trabalho que devem ser regularmente mescladas na Principal. Baseamos nosso novo processo neste artigo e no Guia de ramificação do TFS (estamos usando o TFS e o Visual Studio 2010).

Atualmente, entre 1 e 5 pessoas trabalham no projeto a qualquer momento. Main deve estar estável o tempo todo, porque queremos que a opção seja lançada sempre que precisar. Não temos sprints fixos - pelo menos ainda não - e no momento lançamos a cada 1-2 semanas.

Nesse momento, cada pessoa está corrigindo bugs no aplicativo. Dentro de algumas semanas, iniciaremos o desenvolvimento de um novo componente grande para o aplicativo.

Um ponto de discórdia que estamos descobrindo é quando ramos de desenvolvimento devem ser criados . Implementaremos várias histórias de usuários em paralelo, dependendo do conjunto de habilidades do desenvolvedor. Pensamos em criar uma ramificação para cada desenvolvedor, mas isso não faz sentido, porque sempre haverá alguma necessidade de colaboração em um trabalho. Não podemos conviver com uma única ramificação de desenvolvimento, porque queremos mesclar para Main enquanto outros trabalhos são concluídos.

Alguém tem alguma orientação sobre isso?

Não gosto de ramificações arbitrárias, como as correções de Fred ou de Harry. Estou muito mais à vontade com um recurso (independente), um ramo que permite que vários desenvolvedores operem em um recurso; mas para que o recurso seja mesclado somente quando estiver completo.

Portanto, agora você só precisa do ramo "bugfix", mas quando você inicia o desenvolvimento, deve criar um ramo para cada recurso significativo. Dessa forma, quando concluídos, eles podem ser mesclados e liberados sem depender de outras funcionalidades do buggier.

Não tenho certeza de como o TFS é bom na fusão, mas tenho certeza que você saberá em alguns meses :)

Não podemos nos dar bem com uma única ramificação de desenvolvimento, porque queremos mesclar para Main enquanto outros trabalhos são concluídos.

Parece que você já sabe que vários ramos de desenvolvimento devem ser criados. Dois cenários prováveis ​​vêm à mente:

1. Cada um dos cinco desenvolvedores está trabalhando em partes independentes do projeto (correção de bugs) - Verifique se uma ramificação individual foi criada para cada desenvolvedor. Isso coloca o ônus e a responsabilidade em cada desenvolvedor para garantir que seu conjunto de alterações não entre em conflito com o trabalho de outras pessoas. É altamente provável que um dos seus cinco desenvolvedores cometa um erro. Se / Quando for esse o caso, não faz sentido que todos os outros sejam mantidos.
2. Vários desenvolvimentos de recursos - Independentemente do número de desenvolvedores trabalhando em um recurso / bug específico, eles devem ser separados. Um exemplo disso é benéfico é que todas as confirmações de código fazem parte do (s) recurso (s) que estão sendo desenvolvidos - não há dúvidas.

Ramificações de trabalho implícitas com o DVCS

Usamos o Mercurial para que haja o ramo de trabalho implícito na caixa de desenvolvimento dos desenvolvedores. A confirmação sempre é feita no espaço de trabalho local. Quando um trabalho liberável é concluído, ele é enviado ao servidor de repositório principal, onde é automaticamente construído e testado.

Quase nunca criamos ramificações explícitas, mas, novamente, nossos sprints nunca duram mais de uma semana e os cartões não demoram mais do que 1-2 dias para serem concluídos.

Além disso, você pode atenuar a dor de mesclagem segmentando trabalhos de outras partes do código ou de outros projetos, para que as pessoas não tenham que fazer mesclagens difíceis o tempo todo.

Eu usei ramificação única por história e uma ramificação por versão (todos os desenvolvedores fazem check-in de suas histórias no dev e, se algum deles quebra o ram do dev, está quebrado para todos). Eu recomendo o ramo por história, se você não gosta de conflitos. O ramo dev sempre permanecerá estável para todos os desenvolvedores e não haverá tempo de espera para um desenvolvedor trabalhar em um trecho de código que outro desenvolvedor já quebrou. Quando sua história termina, todo o seu código está no seu ramo. Você o mesclará para o dev, mas não para o check-in e teste, caso haja conflitos, você o resolverá e solicitará à pessoa com quem está em conflito para evitar a remoção do código. Em seguida, mesclar para dev. Isso ajuda todos os desenvolvedores a funcionarem sem problemas. Também depende do tamanho da empresa. Nossa empresa possui 200 desenvolvedores trabalhando simultaneamente em uma base de código, mas ramo separado para suas histórias. Depois que o código é mesclado ao ramo de desenvolvimento, o ramo da história é excluído imediatamente. Eu espero que isso ajude. obrigado

Se isso for baseado no git, basta criar uma ramificação para cada correção de bug, corrigir o bug no menor tempo possível, mesclar o ramo de correção de bug com o ramo de desenvolvimento e enviar a alteração para o ramo de desenvolvimento. A revisão de solicitações pull e a mesclagem devem ser a prioridade mais alta , pois quanto mais rápido você realizar, maiores serão as chances de a mesclagem não causar problemas. Uma vez mesclados, esses ramos podem ser excluídos.