Minha empresa está fundindo sucursais erradas?

Recentemente, deparei com um artigo do MSDN sobre ramificação e mesclagem e SCM: Ramificando e mesclando iniciador - Chris Birmele .

No artigo, eles dizem que 'big bang merge' é um antipadrão em fusão:

Big Bang Merge - adiando a ramificação que se une ao final do esforço de desenvolvimento e tentando mesclar todas as ramificações simultaneamente.

Percebi que isso é muito semelhante ao que minha empresa está fazendo com todos os ramos de desenvolvimento que são produzidos.

Eu trabalho em uma empresa muito pequena, com uma pessoa atuando como autoridade de revisão final + mala direta. Temos 5 desenvolvedores (incluindo eu), cada um de nós terá uma tarefa / bug / projeto separado e cada um dos ramos do tronco atual (subversão) será executado e, em seguida, realizaremos o trabalho de desenvolvimento em nosso ramo, testamos os resultados, escrevemos documentação. se necessário, faça uma revisão por pares e um loop de feedback com os outros desenvolvedores e envie a ramificação para revisão + mesclagem em nosso software de gerenciamento de projetos.

Meu chefe, a única autoridade no repositório de troncos, na verdade adiará todas as revisões de ramificações até um único momento em que ele executará revisões o máximo que puder, algumas ramificações serão devolvidas para aprimoramentos / correções, algumas ramos se fundem diretamente no tronco, alguns ramos serão jogados de volta por causa de conflitos etc.

Não é incomum termos 10 a 20 ramos ativos na fila de revisão final para serem mesclados no tronco.

Também temos frequentemente que resolver conflitos no estágio final de revisão e mesclagem, porque duas ramificações foram criadas no mesmo tronco, mas modificaram o mesmo trecho de código. Normalmente, evitamos isso apenas reorganizando o tronco e reaplicando nossas alterações e resolvendo os conflitos e enviando o novo ramo para revisão (rebase do pobre homem).

Algumas perguntas diretas que tenho são:

• Estamos exibindo o próprio antipadrão que foi descrito como o 'big bang merge'?
• Alguns dos problemas que estamos vendo são resultado desse processo de mesclagem?
• Como podemos melhorar esse processo de mesclagem sem aumentar o gargalo no meu chefe?

Edit: Duvido que meu chefe afrouxe o controle sobre o repositório de troncos ou permita que outros desenvolvedores se unam ao tronco. Não sei quais são suas razões para isso, mas eu realmente não planejo abordar o assunto, porque ele foi abordado antes e abatido rapidamente. Eu acho que eles simplesmente não confiam em nós, o que não faz sentido, porque tudo é rastreado de qualquer maneira.

Qualquer outra visão sobre essa situação seria apreciada.

Algumas sugestões:

• Não há nada errado em ter muitas ramificações de recursos ou correções, desde que as alterações feitas em cada ramificação sejam pequenas o suficiente, e você ainda poderá lidar com os conflitos de mesclagem resultantes de maneira eficaz. Esse deve ser seu critério se sua maneira de trabalhar estiver correta, não em algum artigo do MSDN.

• Sempre que um ramo é mesclado no tronco, o tronco deve ser mesclado em todos os ramos de desenvolvimento abertos o mais rápido possível. Isso permitiria que todas as pessoas da equipe resolvessem conflitos de mesclagem em paralelo em seu próprio ramo e, portanto, sobrecarregassem o porteiro do porta-malas.

• Isso funcionaria muito melhor se o gatekeeper não esperasse até que 10 ramificações estivessem "prontas para serem incorporadas ao tronco" - a resolução de conflitos de mesclagem das últimas integrações de tronco precisa sempre de algum tempo para a equipe; portanto, provavelmente é melhor trabalhar em intervalos de tempo entrelaçados - uma integração pelo gatekeeper, uma re-fusão pela equipe, próxima integração pelo gatekeeper, próxima re-fusão pela equipe e assim por diante.

• Para manter as ramificações pequenas, pode ser útil dividir os recursos maiores em várias tarefas menores e desenvolver cada uma dessas tarefas em uma ramificação própria. Se o recurso não estiver pronto para produção até que todas as subtarefas sejam implementadas, oculte-o da produção atrás de um alternador de recurso até que todas as subtarefas sejam concluídas.

• Mais cedo ou mais tarde, você encontrará tarefas de refatoração que afetam muitos arquivos na base de código - elas têm um alto risco de causar muitos conflitos de mesclagem com muitas ramificações. Essas podem ser tratadas melhor comunicando-as claramente na equipe e certifique-se de lidar com elas exatamente como eu escrevi acima: integrando-as primeiro em todos os ramos de desenvolvimento antes da reintegração e dividindo-as em sub-refatorações menores.

• Para o tamanho atual da sua equipe, ter um único gatekeeper ainda pode funcionar. Mas se sua equipe crescer em tamanho, não há como contornar um segundo guardião (ou mais). Observe que não estou sugerindo permitir que todos entrem no tronco, mas isso não significa que apenas seu chefe seja capaz de fazer isso. Provavelmente, há um ou dois desenvolvedores seniores que também poderiam ser candidatos para o trabalho do porteiro. E mesmo para o tamanho da sua equipe atual, um segundo gatekeeper poderia facilitar a integração da sua equipe ao tronco com mais frequência e mais cedo, ou quando seu chefe não estiver disponível.

Estamos exibindo o próprio antipadrão que foi descrito como o 'big bang merge'?

Parece que sim.

Alguns dos problemas que estamos vendo são resultado desse processo de mesclagem?

Definitivamente

Como podemos melhorar esse processo de mesclagem sem aumentar o gargalo no meu chefe?

Na minha empresa, todo desenvolvedor tem a capacidade de mesclar. Atribuímos uma solicitação de mesclagem a outro desenvolvedor, passamos pelo ciclo de revisão / feedback / atualização até que ambas as partes estejam satisfeitas. Em seguida, o revisor mescla o código.

De 10 a 20 filiais aguardando fusão, é um sinal de que seu processo está com defeito. Se tivéssemos tantos, todo o trabalho de desenvolvimento parava até que fosse esclarecido.

É basicamente assim que muitos projetos de código aberto funcionam, incluindo o kernel Linux, que tem muito mais ramificações do que você em um determinado momento. A maneira típica de evitar mesclagens do big bang nesses projetos é criar outra ramificação (ou várias ramificações) para integração contínua. Esse é o ramo que você usa para garantir que suas alterações funcionem em conjunto com seus colegas, e ele é periodicamente reencaminhado para o tronco quando o gatekeeper faz as revisões.

Opcionalmente, você pode usar essa ramificação para combinar várias de suas próprias solicitações pull em uma grande solicitação coesa para que seu chefe analise. Linus Torvalds normalmente recebe solicitações pull que foram integradas em dois ou mais níveis de profundidade e podem ter um tamanho da ordem de, por exemplo, um novo driver de sistema de arquivos completo.

Concordo com o Doc Brown, mas também vejo outro antipadrão:

Meu chefe, a única autoridade no repositório de troncos , na verdade adiará todas as revisões de ramificações até um único momento em que ele executará revisões o máximo que puder, algumas ramificações serão devolvidas para aprimoramentos / correções, algumas ramos se fundem diretamente no tronco, alguns ramos serão jogados de volta por causa de conflitos etc.

Na minha humilde, existem alguns antipadrões de gestão:

1. Ele / ela é o único ponto de estrangulamento que restringe a velocidade da equipe. Seu fator de barramento é 1. A teoria das restrições diz que você deve se esforçar para melhorar a parte mais lenta da cadeia.
2. Seu gerente está tornando seu ciclo de feedback mais lento e reduzindo a agilidade da sua equipe. Você pode liberar toda semana?
3. Mescla complexidade cresce exponencialmente com a quantidade de código. É melhor fazer 10 mesclagens com 100 linhas que 1 de 1000 linhas. Essa é apenas uma das razões pelas quais você deve fazê-lo o mais rápido possível
4. Se você detectar uma falha no tronco, fará isso mais tarde. Qual dos vários ramos foi o problemático
5. As decisões devem ser tomadas por aqueles que têm mais conhecimento sobre elas. Quem sabe mais nesse caso? Aposto que os desenvolvedores que criaram o código.
6. Você não pode corrigir um erro na produção se o seu gerente estiver nos feriados.
7. Você está refazendo o trabalho e jogando de volta galhos. Isso é uma perda de tempo. O tempo de espera para chegar à produção também é desperdício.

Recomendações:

• Seu gerente precisa delegar responsabilidade à equipe. Você precisa mostrar que a equipe é madura, profissional. Deixe claro que eles podem confiar na equipe
• Implemente algum método de revisão. Pode ser que você precise da aprovação de outros dois membros da equipe.
• Talvez o uso do SVN esteja dificultando. Experimente o Git e veja se isso ajuda você. Ainda mais. Se você usa o GitHub, pode usar o mecanismo Pull Request para que uma mesclagem exija certos votos.
• Leia e compartilhe informações sobre práticas ágeis, integração contínua e DevOps.

Quando você trabalha com recursos em ramificações separadas, não pode realizar facilmente nenhum teste de integração até que uma das ramificações seja mesclada ao tronco e puxada para as outras ramificações de recursos. Na minha experiência, esse é o principal problema com o antipadrão do Big Bang Merge. Idealmente, você faria o trabalho do recurso, testaria-o na ramificação do recurso, mesclaria-o no tronco e, nesse ponto, estará pronto com o recurso. Se não tiver sido mesclado, você deverá revisá-lo sempre que algo mais for mesclado ao tronco antes dele. A dor desse antipadrão é que você tem muitos bugs do tipo integração que aparecem no final do ciclo de desenvolvimento.

Então você tem 20 filiais. A ramificação 1 é apenas mesclada. Em seguida, o desenvolvedor da ramificação 2 precisa mesclar a ramificação 1 em sua ramificação para poder mesclar na main sem conflito, e depois se mescla. Em seguida, o desenvolvedor da ramificação 3 precisa mesclar a ramificação 1 e a ramificação 2 em sua ramificação para poder mesclar a main sem conflito e, em seguida, mesclar.

Exercício para o leitor: escreva um programa que imprima meu post completo :-)

Isso é loucura. Você estará gastando uma quantidade incrível de tempo se fundindo.

Dada a maneira como você trabalha e que seu chefe é um maníaco responsável pelo controle, a ramificação parece ser o problema. Em vez de criar uma ramificação para cada recurso, peça a cada desenvolvedor confirmar seu recurso em partes, diretamente no tronco. Isso coloca o ônus da integração no desenvolvedor em várias etapas menores (ganha-ganha). O gatekeeper pode acompanhar as alterações menores por um período mais longo no início do ciclo de desenvolvimento e ainda ser o revisor principal.

Ramificar em si é algo que você não deseja fazer, a menos que tenha um bom motivo para fazê-lo ou não tenha outra opção. Você é pequeno o suficiente para manter as coisas sincronizadas com mais força, o que será mais fácil e seguro.