Como você lida com a integração de código de vários ramos / desenvolvedores em cada sprint?

Se você estiver usando o Git, cada desenvolvedor estará puxando da ramificação develop para o seu próprio ramo de recursos para garantir que eles não vão muito longe da linha de base atual. Eles podem fazer isso diariamente, de modo que as tarefas que demoram mais de alguns dias para ficar em sincronia e mesclar problemas sejam resolvidas enquanto ainda são pequenas.

Quando o desenvolvedor termina seu trabalho, ele cria uma solicitação pull . Quando aprovado, ele é mesclado na ramificação develop .

A ramificação develop deve sempre ter código de trabalho e estar pronta para ser liberada a qualquer momento. Quando você realmente faz um lançamento, você mescla develop em master e marca.

Se você tiver um bom Continuous Integration Server, ele criará cada ramificação quando as alterações forem verificadas, principalmente para solicitações pull. Alguns servidores de compilação integram-se ao seu servidor Git para aprovar ou reprovar automaticamente uma solicitação pull se a compilação falhar ou se os testes automatizados falharem. Esta é outra maneira de encontrar possíveis bugs de integração.

Eu trabalhei em uma equipe onde lutamos com o mesmo problema. Descobrimos que quanto menos tempo tínhamos antes da integração, menos difícil se tornava. Eu sei que a maioria das pessoas que ensinam integração contínua fala sobre cometer a cada poucos minutos - nós provavelmente realmente cometemos a cada hora ou mais.

Também descobrimos que apenas construir não era suficiente. Precisávamos de um bom nível de cobertura de teste para garantir que não quebrássemos acidentalmente o código dos outros.

• Mantenha seus galhos de vida curta (parece que você já está fazendo isso).
• Deixe seus resultados de teste falarem por si mesmos.
• Não espere o fim do sprint.

Você nem precisa se inscrever no TDD para este. Tudo o que você precisa são alguns testes que provam que os recursos de seus desenvolvedores estão funcionando corretamente. Estes podem incluir Testes Unitários e Testes de Integração, mas idealmente serão alguns testes automatizados de ponta a ponta dos recursos críticos. Material do pacote de regressão padrão.

Em seguida, depois que sua mesclagem for concluída, você poderá verificar o relatório de teste de automação e verificar se tudo foi integrado com êxito.

Concordo com uma das outras respostas em que o autor afirmou que o Git PRs resolveria esse problema fazendo com que cada desenvolvedor mescle seu próprio trabalho.

Um outro ponto que acredito ser importante o suficiente para sair até o último parágrafo. Eu sugiro que você execute testes manuais sobre suas construções noturnas, ao invés de esperar até o final do sprint. Os desenvolvedores devem se integrar assim que o recurso estiver completo, para que possa ser integrado, implantado e testado o mais rápido possível.

Não

Dependendo do seu idioma e dos arquivos que você está editando, pode não fazer sentido para cada desenvolvedor editá-los em sua própria ramificação. Por exemplo, em C #, descobri que é melhor que apenas uma pessoa edite qualquer arquivo de designer de UI por vez. Esses são arquivos autogerados e, assim, o código às vezes é movido sem motivo aparente - e isso causa estragos na maioria das ferramentas de mesclagem.

Isso significa que algumas histórias podem bloquear outras histórias até que o trabalho da UI seja concluído. E / ou, uma nova história é criada para apenas layout da interface do usuário, com as outras histórias implementando funcionalidade. Ou talvez um desenvolvedor faça toda a interface do usuário funcionar enquanto outros implementam a funcionalidade dessa interface do usuário.

Em uma nota relacionada, se você souber que várias histórias estarão tocando no (s) mesmo (s) arquivo (s), talvez você queira evitar trabalhar com todas elas ao mesmo tempo. Não os puxe todos no mesmo sprint, ou não comece a trabalhar em todos eles até que um ou mais estejam prontos.

Outra abordagem possível para evitar fusões tardias e grandes são flags de recursos : você protege suas alterações com um sinalizador (idealmente dinâmico) configurável que impede que elas se tornem ativas antes do planejado.

Isso permite que você mescle suas alterações no início de volta em master ou em sua ramificação de desenvolvimento conjunta sem quebrar nada. Outros desenvolvedores podem, então, mesclar essas alterações de volta em seus ramos de recursos (ou rebase seus ramos de acordo).

Como as outras respostas já apontaram, isso deve ser combinado com uma solução de integração contínua.

Os sinalizadores de recursos têm benefícios adicionais (por exemplo, facilitam a realização de testes A / B). Consulte este artigo de Martin Fowler para obter mais informações.

Estamos seguindo uma abordagem de ramificação de desenvolvimento separada para cada recurso e, em seguida, estamos mesclando as ramificações em uma ramificação de QA para testes no ambiente de teste de integração.

Depois que os testes de regressão e integração estiverem concluídos, movemos facilmente os recursos que estão prontos para o ramo de lançamento.

Se tudo correr bem, nós mesclamos a ramificação de lançamento de volta ao ramo principal.

As outras respostas fornecem algumas dicas sobre as práticas recomendadas para os commits e, simplesmente seguindo essas, você provavelmente reduzirá a grande maioria de seus problemas de mesclagem. Mais fusões são quase certamente uma necessidade, mas para uma equipe menor, sua abordagem ramo a pessoa provavelmente funciona bem o suficiente. É claro que não faz mal (muito) entrar em práticas mais extensíveis!

No entanto, ninguém parece ter abordado uma de suas perguntas mais importantes - o que fazer quando todos vocês estão tocando as mesmas áreas de código. É aqui que é útil ter um lead que esteja familiarizado com a base de código e possa reconhecer dependências de tarefas diferentes. Se eles não orquestram o tempo de trabalho e confirmações, você provavelmente terminará com conflitos de mesclagem e resolução de linha por linha. Organizar o timing das tarefas é muito mais difícil com uma equipe maior, mas com uma pequena equipe é possível identificar essas tarefas conflitantes. O líder poderia, então, até mesmo transferir todas as tarefas relacionadas para o mesmo engenheiro, para evitar completamente o conflito.