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

Acabei de receber uma ligação retro, onde os desenvolvedores expressaram preocupação com a integração de suas histórias no ramo principal a cada sprint. Todos os desenvolvedores codificam dentro de sua própria ramificação e, no final do sprint, todos se fundem em uma ramificação principal.

Em seguida, um desenvolvedor (geralmente o mesmo) fica com a tarefa de garantir que tudo se integre bem ao código de outros desenvolvedores (a maioria das alterações está na mesma página. Por exemplo, uma história de exibição de dados, história de filtragem de dados e um indicador de SLA).

Como podemos reduzir esse fardo e facilitar a mesclagem de nosso código? Na minha perspectiva, fazer com que o PO ou SM priorize as histórias de maneira mais eficiente, para que não tenhamos esse tipo de dependência no mesmo sprint, pode resolver alguns dos problemas. Como todo mundo lida com isso? Ou isso é apenas parte do processo?

Se você estiver usando o Git, cada desenvolvedor puxará da developramificação para sua própria ramificação de recursos, para garantir que eles não fiquem muito longe da linha de base atual. Eles podem fazer isso diariamente, para que as tarefas que levam mais de alguns dias permaneçam em sincronia e os problemas de mesclagem sejam resolvidos enquanto ainda são pequenos.

Quando o desenvolvedor termina seu trabalho, ele cria uma solicitação de recebimento . Quando aprovado, isso é mesclado na developramificação.

A developramificação deve sempre ter código de trabalho e estar pronta para liberação a qualquer momento. Quando você realmente faz um lançamento, mescla develop-o mastere marca-o.

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

Eu trabalhei em uma equipe onde lutamos com o mesmo problema. Descobrimos que quanto menos tempo tínhamos antes de integrar, menos difícil se tornava. Eu sei que muitas pessoas que ensinam integração contínua falam sobre cometer a cada poucos minutos - provavelmente, na verdade, cometemos a cada hora mais ou menos.

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 um do outro.

• Mantenha seus galhos de curta duração (parece que você já está fazendo isso).
• Deixe os resultados dos seus testes falarem por si mesmos.
• Não espere o final do sprint.

Você nem precisa se inscrever no TDD para este. Tudo que você precisa são de alguns testes que provam que os recursos de seus desenvolvedores estão funcionando corretamente. Isso pode incluir testes de unidade e testes de integração, mas, idealmente, serão dois testes automatizados de ponta a ponta dos recursos críticos. Material do pacote de regressão padrão.

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

Concordo com uma das outras respostas em que o autor declarou que os Git PRs resolveriam esse problema, fazendo com que cada desenvolvedor mesclasse seu próprio trabalho.

Outro ponto que considero importante o suficiente para deixar até o último parágrafo. Sugiro que você execute testes manuais em suas compilações noturnas, em vez de esperar até o final do sprint. Os desenvolvedores devem se unir assim que o recurso estiver completo, para que ele 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 suas próprias ramificações. Por exemplo, em C #, achei melhor apenas uma pessoa editar os arquivos de designer de interface do usuário de cada vez. Esses arquivos são gerados automaticamente e, portanto, 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 até que o trabalho da interface do usuário seja concluído. E / ou, uma nova história é criada apenas para o layout da interface do usuário, com as outras histórias implementando a funcionalidade. Ou talvez um desenvolvedor faça toda a interface do usuário, enquanto outros implementam a funcionalidade dessa interface.

Em uma nota relacionada, se você souber que várias histórias tocarão no mesmo arquivo, evite trabalhar nelas ao mesmo tempo. Não coloque todos no mesmo sprint ou não comece a trabalhar até que um ou mais estejam concluídos.

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

Isso permite que você mescle suas alterações antecipadamente de volta ao masterramo de desenvolvimento conjunto ou a ele sem interromper nada. Outros desenvolvedores podem mesclar essas alterações novamente em suas ramificações de recursos (ou refazê-las 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). Veja 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 controle de qualidade para teste no ambiente de teste de integração.

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

Se tudo correr bem, mesclamos o branch de liberação novamente para o branch master.

Simplificando, confirmar e mesclar muitas vezes reduz a janela de oportunidade para conflitos de mesclagem e reduz bastante os conflitos. A outra parte é realmente planejar pelo lead, o que pode garantir ainda mais que o trabalho flua sem problemas.

As outras respostas oferecem uma excelente visão sobre as práticas recomendadas para confirmações e, seguindo essas, você provavelmente reduzirá a grande maioria dos seus problemas de mesclagem. Mais combinações são quase certamente uma necessidade, mas para uma equipe menor, sua abordagem de ramo por pessoa provavelmente funciona bem o suficiente. Claro, não dói (muito) entrar em práticas mais extensíveis!

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