Qual é a melhor maneira de lidar com versões de produtos e ramificações de projetos de longo prazo?

De um modo geral, para projetos de longo prazo que podem ter várias liberações durante o ciclo de vida dos produtos e requerem suporte de produtos anteriores, qual é a melhor maneira de lidar com versões de produtos e ramificações da base de código?

Em um sentido mais específico, suponha que o controle de versão distribuído adequado esteja em vigor (ou seja, git) e que as equipes sejam de tamanho pequeno a grande e que o desenvolvedor possa estar trabalhando em vários projetos ao mesmo tempo. O principal problema que está sendo enfrentado é que existe uma obrigação contratual de oferecer suporte a versões antigas, uma vez que existiam na época, o que significa que o novo desenvolvimento não pode corrigir o código antigo (os produtos do Microsoft Office podem ser um exemplo disso, você só obtém patches para o ano que você possui).

Como resultado, a versão atual do produto é um pouco complicada, pois cada produto principal possui várias dependências, cada uma com suas próprias versões, que podem ser alteradas entre as liberações anuais. Da mesma forma, embora cada produto tenha seu próprio repositório, a maior parte do trabalho não é realizada no tronco de origem principal, mas em uma ramificação para o ano em que o lançamento do produto é feito com uma nova ramificação quando o produto é liberado para que possa ser suportado. Isso, por sua vez, significa que obter a base de código de um produto não é uma questão simples, como se pode pensar ao usar o controle de versão.

Quanto (e que tipo de) estrutura você precisa depende muito do que você deseja poder fazer. Descubra o que você não pode viver sem, o que você quer ter e com o que você não se importa.

Um bom exemplo de conjunto de decisões pode ser:

Coisas que não podemos viver sem:

• ser capaz de reconstruir qualquer versão anterior a qualquer momento
• poder manter várias versões principais suportadas do produto a qualquer momento

Coisas que gostaríamos de ter:

• ser capaz de executar o desenvolvimento contínuo de recursos principais (para a próxima versão principal) sem se preocupar com mesclagens de filiais
• ser capaz de executar atualizações de manutenção para versões anteriores

Coisas que podemos viver sem:

• backport automático de alterações do trabalho atual para versões anteriores
• nunca interrompa o desenvolvimento de recursos importantes, mesmo que por alguns dias ou uma semana de cada vez

Se os objetivos acima fossem seus, você poderia adotar um processo como este:

1. Faça todo o trabalho de desenvolvimento no tronco do seu VCS ("mestre" no git)
2. Quando você estiver próximo de uma versão principal, interrompa o desenvolvimento de recursos importantes e concentre-se na estabilidade do sistema por uma semana ou mais
3. Quando o tronco parecer estável, crie um ramo para esta versão principal
4. Agora, o desenvolvimento dos principais recursos pode prosseguir no tronco, enquanto apenas correções de bugs e preparação de versões são permitidas na ramificação
5. No entanto, todas as correções a serem feitas na ramificação devem primeiro ser testadas no tronco; isso garante que eles também estarão presentes em todas as versões futuras
6. Crie uma tag (VCS) na ramificação quando estiver pronto para liberar; essa tag pode ser usada para recriar a versão a qualquer momento, mesmo depois de mais trabalho na mesma ramificação
7. Agora, novas versões de manutenção desta versão principal (versões secundárias) podem ser preparadas na filial; cada um será marcado antes do lançamento
8. Enquanto isso, o desenvolvimento dos principais recursos voltados para o próximo grande lançamento pode continuar no tronco
9. Quando você se aproximar desse release, repita as etapas acima, criando um novo ramo de releases para esse release . Isso permite que você tenha várias versões principais, cada uma em sua própria ramificação, no status suportado ao mesmo tempo, com a capacidade de liberar versões secundárias separadas contra cada uma.

Esse processo não responde a todas as suas perguntas - em particular, você precisará de um processo para decidir quais correções podem ser feitas em uma ramificação de liberação e garantir que os erros não sejam corrigidos primeiro em uma ramificação de liberação (tais correções sempre deve ser testado no tronco sempre que possível). Mas isso lhe dará uma estrutura para tomar essas decisões.

"Longo prazo" é um indicador de que você precisa de controle de versão, mas não implica nenhuma estratégia específica de controle de versão e ramificação. A questão mais interessante é quantas linhas de produtos ou linhas de versão principais você deseja oferecer suporte (que depende do contrato com seus clientes). Você precisará de pelo menos uma filial para cada linha de produto / linha de versão principal para a qual tenha um contrato de manutenção.

Por outro lado, depende do tamanho da sua equipe. Se você tem uma grande equipe de desenvolvimento, com pessoas diferentes trabalhando em diferentes recursos em paralelo, obviamente precisará de mais ramificações de recursos do que se tiver uma equipe de uma ou duas pessoas. Se você estiver trabalhando com uma equipe maior, considere usar o controle de versão distribuído, o que torna o trabalho paralelo em diferentes ramos (e reintegrá-los posteriormente no tronco) muito mais eficiente.

Git é uma ferramenta de controle de versão - ele gerencia versões de arquivos. O que você procura é uma ferramenta de gerenciamento de configuração. Existem muitas dessas opções disponíveis, mas principalmente com preços altos de empresas como a IBM.

As ferramentas de controle de versão fornecem ramificação e marcação, o que permite o gerenciamento de configurações precisas sem suporte adicional a ferramentas; portanto, os desenvolvedores podem não entender a diferença. Suas necessidades provavelmente vão além do que o GIT foi projetado para fazer.

Não estou ciente, mas tenho certeza de que ela existirá, uma adição à ferramenta CM para o Git.

Esta pergunta parece ser muito semelhante a outra pergunta que respondi recentemente.

Em resumo, isso parece mais um problema de design e distribuição de produto do que um problema de controle de versão / ramificação. Claro, é fácil para mim dizer isso e mais difícil para você corrigir se você já está profundamente envolvido no problema.

Sem conhecer em detalhes os detalhes do seu problema específico. No entanto, em geral, se eu tivesse várias versões de produtos com base em uma base de código que tivesse uma grande quantidade de código compartilhado entre produtos, se fosse viável, procuraria refatorar produtos de uma maneira que os tornasse mais modulares e garantir que os próprios módulos não exijam ramificação adicional de código. Também examinaria meu modelo de implantação, para ver se havia um meio melhor de oferecer suporte aos meus clientes, mantendo ainda grande parte da base de código unificada. Onde a personalização específica do cliente é necessária, uma granularidade maior dos módulos pode ser necessária para reduzir a quantidade de código duplicado no sistema.

Não é uma tarefa fácil, mas pode ser corrigida em etapas se você gerenciar bem o trabalho e se puder agendá-lo para não precisar "atualizar" tudo de uma só vez.