Como posso trabalhar simultaneamente na versão 1.1 e na versão 2.0?

Question

A situação:Saímos do beta e a versão 1.0 foi lançada para vários sites de clientes.A Equipe A já está ocupada trabalhando na versão 1.1, que terá correções incrementais de bugs e ajustes de usabilidade, enquanto outra equipe trabalha na versão 2.0 com mudanças em grande escala, onde o núcleo do produto pode ter sido completamente redesenhado.Agora, a maioria das alterações feitas na versão 1.1 terão que chegar à versão 2.0 em algum momento, e algumas das correções de bugs feitas na versão 2.0 podem, de fato, precisar ser agendadas para uma versão anterior.O problema é que como o 2.0 tem diferenças fundamentais, nenhuma alteração do 1.1 pode ser mesclada sem conversão manual, nem vice-versa.

Minha pergunta:Quais são as melhores práticas de controle de revisão para minimizar conflitos de mesclagem e trabalho duplicado nesse tipo de situação?Como posso garantir que minhas equipes gastem o mínimo de tempo e esforço possível em questões de controle de revisão e, ao mesmo tempo, forneçam patches regulares aos clientes?

Answer 1

Uma boa maneira é corrigir cada bug no branch estável e mesclar o branch estável no branch de desenvolvimento.Isto é o Linhas Paralelas de Manutenção/Desenvolvimento padrão, e a chave é mesclar cedo e com frequência.Mesclar com pouca frequência e tarde significa que o branch de desenvolvimento está irreconhecível em comparação com o estável, ou o bug não pode ser repetido da mesma maneira.

Subversão inclui rastreamento de mesclagem desde a versão 1.5 para garantir que o mesmo conjunto de alterações não seja mesclado duas vezes, causando conflitos bobos.Existem outros sistemas (por ex. Git, Mercurial, Accurev, Forçosamente) que permitem fazer consultas do tipo "O que as mudanças na filial A não foram fundidas no ramo B?" E escolha as correções necessárias para o ramo dev.

Answer 2

O artigo aqui (Dia-a-dia com Subversion) menciona que um método é atualizar constantemente a versão 2 com dados da versão 1.1.Na matéria, o cara fala para fazer isso todos os dias.

A parte que você vai querer ler é intitulada "Garçom, tem um bug no meu porta-malas!".Está na metade do artigo.

Answer 3

Eu provavelmente confiaria em um sistema de rastreamento de problemas para essa finalidade e certificar-me-ia de marcar cada alteração que precisasse ser trazida para o código de tronco.Você pode então garantir que os comentários de check-in para cada alteração façam referência ao problema relevante e sejam claros ao expressar a intenção da alteração do código, para que ela possa ser facilmente compreendida ao tentar reimplementar no tronco.

Answer 4

Praticamente o que todo mundo disse, mas decidi contar com minha experiência em lidar com o desenvolvimento em vários ramos usando SVN

Com nosso produto principal, temos a necessidade de desenvolver simultaneamente em mais de 2 versões ao mesmo tempo.

Originalmente, usei o tronco principal como a versão de "desenvolvimento principal", com tags usadas para cada versão real.As ramificações foram usadas para esforços substanciais de desenvolvimento de um novo conjunto de recursos.Mais tarde, quando começamos a trabalhar em 2, 3 e 4 versões por vez, comecei a usar um branch para cada revisão.

Como eu mantenho o repositório e também cuido do envio de compilações de controle de qualidade, certifico-me de fazer "rollups" todas as manhãs - que consiste em mesclar as alterações na árvore, começando com o branch ativo mais baixo no momento.Então acabo mesclando as alterações de 1.1 em 1.2, que são mescladas em 1.3 com quaisquer outras alterações de 1.2 desde a última mesclagem, etc.

Quando eu me comprometo, sempre comento o commit com algo como

mesclado 1.1 rev 5656-5690

Pode ser um pouco chato, mas funciona :)

Answer 5

Mescle antecipadamente, mescle com frequência e certifique-se de que o controle de qualidade na linha principal conheça e regresse/verifique os defeitos corrigidos em cada patch das versões de manutenção.

É realmente fácil deixar algo escapar e "descorrigir" um bug em uma versão subsequente, e deixe-me dizer, os clientes não se importam com o quão complicado pode ser gerenciar várias filiais - esse é o seu trabalho.

Certifique-se de usar um sistema de controle de origem que suporte ramificação e fusão (tive experiência com Perforce e SVN e, embora o Perforce seja melhor, o SVN é gratuito).

Acredito também que ter uma única pessoa responsável por realizar as fusões de maneira consistente ajuda a garantir que elas aconteçam regularmente.Geralmente sou eu ou um dos funcionários seniores da nossa equipe.

Answer 6

A maneira como lidamos com isso no meu trabalho é manter o branch trunk como o código mais avançado (ou seja, 2.0 neste caso).Você cria uma ramificação para o código 1.x e faz todas as correções lá.Quaisquer alterações na versão 1.x devem ser mescladas (manualmente, se necessário) na ramificação trunk (2.0).

Eu insistiria então que os desenvolvedores 1.x anotassem o número da revisão do commit 1.x e o número da revisão da mesclagem 2.0 no ticket desse bug.Dessa forma, será mais fácil perceber se alguém se esquece de mesclar suas alterações, e o fato de ter que acompanhar isso o ajudará a lembrar.

Answer 7

Um ponto-chave é capturado em esta imagem do Doutor da Construção:mesclar apenas uma direção.

Answer 8

Para responder a essa pergunta específica, muitos desenvolvedores mudaram do Subversion para o Git.Confira github.com.