Como fazer a transição de uma realidade complexa de ramificação para um modelo de ramificação única?

Em grandes organizações, o uso da metodologia em cascata normalmente resulta em estruturas de ramificação muito complexas (também conhecidas como ramificações de espaguete ).

Quais estratégias de ramificação podem ser usadas para fazer a transição de uma realidade complexa de ramificação para um modelo de ramificação única, como o desenvolvimento baseado em tronco?

Atualizar:

Para esclarecer, a questão é sobre a migração / transição em si , não sobre as metodologias antes e depois, que são bastante claras.

Na verdade, não pode ser "na EOB hoje ainda estamos em cascata com um zilhão de galhos, mas amanhã a primeira coisa será a mudança para o CI de tronco único e ramo único".

Como você mencionou o waterfall, eu entendo que os vários ramos que você está aludindo são ramos de recursos em vez de ramos de manutenção.

Nesta configuração, também presumo que essas ramificações sejam criadas de acordo com um plano em cascata que tenta minimizar conflitos. Isso implica que o objetivo do desenvolvimento é produzir vários produtos distintos. Ao usar um modelo de desenvolvimento de ramificação única, é importante também trabalhar em um único produto. Se vários produtos são desenvolvidos simultaneamente em um modelo de desenvolvimento de ramo único, ele efetivamente "cola" versões desses produtos, para que possamos ter na versão a do repositório um produto saudável X e um produto com bugs Y , enquanto na versão b o produto X tem uma regressão e Y uma correção de bug, mas não temos uma versão em que X eVocê é saudável. Tal situação nos forçaria a considerar X e Y como sendo desenvolvidos em repositórios distintos, o que é uma sugestão de que deveriam ser.

Portanto, as primeiras etapas devem executar uma divisão do repositório :

1. Organize o repositório para que seja fácil dividi-lo em vários pequenos repositórios. Por exemplo, reorganize o repositório atual para que cada diretório de nível superior corresponda ao repositório que você deseja criar no futuro. Ao fazer isso, você pode continuar usando a disciplina de espaguete com galhos com quem todos estão familiarizados.

2. Quando a etapa 1 for concluída, refine a disciplina de ramificação-espaguete , exigindo que qualquer ramificação única toque apenas os arquivos em um diretório de nível superior.

3. Quando cada ramificação estiver em conformidade com a etapa 2, execute a divisão. Os desenvolvedores podem converter facilmente suas alterações pendentes para corrigir um único repositório, apenas removendo o primeiro nível do caminho.

Agora que a divisão foi realizada, você pode começar a trabalhar na própria disciplina de ramificação.

4. Introduzir técnicas de programação que ajudem o desenvolvimento de ramificações de vida curta. As ramificações de vida curta são um aspecto crucial de todas as metodologias de ramificação única. Um de seus objetivos é reduzir o tempo gasto na fusão e depuração de ramos de longa duração. Uma técnica popular é a introdução de "feature-flags", em que uma "factory" usa uma configuração para produzir a versão histórica de um objeto ou a nova versão inicialmente desenvolvida parcialmente desse objeto.

5. Até agora, você tem zilhões de repositórios com apenas algumas ramificações em cada uma e pode ativar o botão "adotamos globalmente a disciplina de desenvolvimento baseada em tronco", sem ver a montanha original de espaguete com ramificação entrando em colapso no tronco.

A divisão real dos repositórios pode ser opcional, mas você precisará adotar políticas que definam claramente o escopo permitido de cada patch enviado (para limitar o risco de conflitos ao mesclar alterações na ramificação principal). Reduzir a sobrecarga vinculada a conflitos é um dos objetivos das metodologias de modelo de ramo único, portanto, presumo que isso seja relevante em seu contexto.

Ao migrar de algo para outro, há apenas duas coisas que você precisa definir:

1. Qual é o seu alvo
2. Como chegar lá (o plano de migração)

A primeira parte é, infelizmente, muitas vezes esquecido ou forma muito vaga. Você não pode simplesmente dizer que o que tem é uma bagunça e deseja organizá-lo. O que isso significa? Todo mundo teria uma interpretação diferente (aka: cada dev pensa que sua ou sua maneira de fazer as coisas é a melhor).

Provavelmente, todos os ramos que você tem estão servindo ou serviram a um propósito. Sem um processo-alvo claramente definido, as pessoas continuarão fazendo o que funciona para elas da maneira que melhor lhes convier (e com razão).

Por exemplo, seu destino deve ser definido tão claramente quanto Vincent Driessen definiu seu "modelo de ramificação Git bem-sucedido" . Se você observar esse modelo, é muito preciso: indica onde o código estável deve estar e onde os recursos instáveis ​​devem ser desenvolvidos. Também diz como - e quando - ramificar, atualizar e mesclar de volta. Você sabe para que serve cada ramo e o que fazer com eles. Usamos uma variação do que foi apresentado por Vincent e nossa variação é definida em nosso wiki.

O ponto importante é fazer com que toda a equipe entenda e concorde com um alvo. Pode valer a pena lembrar às pessoas que você não está procurando seu modelo de ramificação favorito pessoal, mas um modelo com o qual todos os membros da equipe possam concordar e usar com facilidade.

Depois de atingir sua meta, você poderá elaborar seu plano de migração. Esse plano pode ser tão longo ou curto quanto você desejar. Eu já vi esse modelo de ramificação imposto da noite para o dia; em outros lugares, foi realizado mais de 2 ou 3 sprints. Não importa muito para mim, enquanto estamos melhorando.

Você pode começar com os "maiores" ou mais importantes ramos. Por exemplo: "a partir de agora, o mestre deve sempre estar em um estado para ser implantado no prod e o ramo dev deve sempre compilar" (ou quaisquer que sejam suas regras). Em seguida, imponha ramificações de versão (liberação). Depois, imponha ramificações de recursos. Depois disso, imponha um congelamento de código na ramificação da versão, se fizer sentido.

DevOps tem tudo a ver com comunicação, abertura e eficiência. Esses conceitos devem ser mantidos em mente e comunicados ao longo do processo.

Sugiro convidar algumas pessoas de fora da equipe de desenvolvimento para a reunião do processo como observadores. Ops ou gerência intermediária podem ter uma coisa ou duas a dizer sobre seu modelo. As necessidades dos desenvolvedores devem ser priorizadas, mas se o modelo de ramificação for impossível de se alinhar com a maneira como as coisas são gerenciadas, você saberia melhor agora e não em um mês ou dois.

Se você tem equipes realmente grandes, tente incluir todos, no entanto. Com equipes muito grandes, você terá duas ou três reuniões de qualquer maneira. Convide os líderes da equipe para a sala, mas tenha um webcast disponível e informe a todos sobre isso. Se alguém tiver uma sugestão ou preocupação, ela poderá expressá-la ao líder da equipe e, se for válida, ela será abordada na segunda ou terceira reunião.

Na verdade, é muito simples converter um repositório hidra multi-ramificado em um único modelo ramificado.

Primeiro, você deseja começar com os ramos que têm a menor diferença entre ele e o mestre ou o tronco. Examine sua idade e relevância. Se eles ainda forem relevantes, comece a mesclá-los e a resolver conflitos. Se eles não forem mais relevantes, exclua-os.

Continue esse processo até conseguir mesclar todas as suas ramificações, resolver todos os conflitos e restar apenas uma única ramificação.

Você pode seguir este esboço simples para começar:

1. Crie uma cópia do seu ramo principal / tronco e chame-o temp_master
2. Encontre o ramo com a maior divergência do mestre / tronco.
3. Determine se a ramificação precisa ser mantida, arquivada ou excluída.
   1. Se precisar ser mantido, continue na etapa 4.
   2. Se precisar ser excluído ou arquivado, exclua e arquive-o e retorne à etapa 2.
4. Repita a etapa 2 para encontrar o próximo ramo com a menor divergência.
5. Mesclar os dois ramos encontrados nas etapas 2 e 3, resolvendo todos os conflitos.
6. Mesclar esses dois ramos em seu temp_masterramo.
7. Teste o código no código temp_master para ver se ele é compilado, compilado e execute outros testes automatizados que você possua.
   1. Se algum teste falhar, volte, descubra o motivo, corrija-o e repita o processo.
   2. Se os testes ainda falharem, escolha dois ramos diferentes para trabalhar.
8. Repita as etapas 2 a 7 até ter apenas dois ramos, seu mestre / tronco e temp_master.
9. Por fim, entre temp_masterno master / trunk e viva com o seu novo modelo de ramificação única.

Para organizações grandes com ciclo de sprint típico de 4 semanas, o Git-Flow é a abordagem preferida, porque você se beneficia da ramificação de recursos A ramificação pronta para produção principal é sempre implantável Além disso, a ramificação mestre é mantida limpa de confirmações indesejadas seguindo dois ciclos de confirmação (da característica para Develope Developramificação) dominar).

Além disso, a ramificação também é determinada pela frequência dos lançamentos de produção. Para uma implantação frequente da produção, é melhor ter uma ramificação de recursos ou um modelo centralizado. Nesse caso, a sobrecarga do gerenciamento de filiais é transferida para testes robustos em ambientes inferiores para manter a estabilidade da produção.