Dores de cabeça usando controle de versão distribuído para equipes tradicionais?

Embora eu use e goste do DVCS para meus projetos pessoais, e possa ver totalmente como isso facilita o gerenciamento de contribuições de outras pessoas (por exemplo, o seu cenário típico do Github), parece que para uma equipe "tradicional" pode haver alguns problemas durante o processo. abordagem centralizada empregada por soluções como TFS, Perforce, etc. (por "tradicional", quero dizer uma equipe de desenvolvedores em um escritório trabalhando em um projeto que nenhuma pessoa "possui", com potencialmente todos tocando o mesmo código.)

Eu já previ alguns desses problemas sozinho, mas por favor, fale com outras considerações.

Em um sistema tradicional, quando você tenta verificar sua alteração no servidor, se alguém já fez check-in em uma alteração conflitante, você é forçado a se unir antes de poder fazer o check-in. No modelo DVCS, cada desenvolvedor faz check-in muda localmente e, em algum momento, empurra para outro repositório. Esse repositório, em seguida, tem um ramo desse arquivo que 2 pessoas mudaram. Parece que agora alguém deve ser encarregado de lidar com essa situação. Uma pessoa designada na equipe pode não ter conhecimento suficiente de toda a base de código para poder lidar com a mesclagem de todos os conflitos. Portanto, agora foi adicionada uma etapa extra em que alguém precisa se aproximar de um desses desenvolvedores, dizer a ele para fazer a fusão e depois pressionar novamente (ou você deve criar uma infraestrutura que automatize essa tarefa).

Além disso, como o DVCS tende a tornar o trabalho local tão conveniente, é provável que os desenvolvedores acumulem algumas alterações em seus repositórios locais antes de enviá-los, tornando esses conflitos mais comuns e mais complicados.

Obviamente, se todos da equipe trabalharem apenas em diferentes áreas do código, isso não é um problema. Mas estou curioso sobre o caso em que todos estão trabalhando no mesmo código. Parece que o modelo centralizado força os conflitos a serem tratados com rapidez e frequência, minimizando a necessidade de fazer fusões grandes e dolorosas ou fazer com que alguém "policie" o principal repositório.

Portanto, para aqueles que usam um DVCS com sua equipe em seu escritório, como você lida com esses casos? Você considera seu fluxo de trabalho diário (ou mais provável, semanalmente) afetado negativamente? Existem outras considerações das quais devo estar ciente antes de recomendar um DVCS no meu local de trabalho?

Estamos usando o Mercurial há cerca de um ano. Embora a dor de cabeça que você menciona exista, de longe, o maior desafio para a adoção completa para nós foi entrar na mentalidade DVCS dos repositórios locais (= confirmar frequentemente). vai.

Você disse:

No modelo DVCS, cada desenvolvedor verifica suas alterações localmente e, em algum momento, envia para outro repositório. Esse repositório, em seguida, tem um ramo desse arquivo que 2 pessoas mudaram. Parece que agora alguém deve ser encarregado de lidar com essa situação.

Uma instalação padrão do Mercurial bloqueia esse comportamento. Não será permitido empurrar se mais de uma cabeça for criada no repositório remoto, sem confirmação extra. Para atividades diárias, evitamos isso. (O Git nomeou chefes e cada um só pode ser atualizado se mesclar completamente a versão anterior, sem confirmação extra; portanto, novamente a situação não pode surgir. Os outros DVCS também têm proteção semelhante.)

Portanto, no final de cada dia útil, é necessário reservar algum tempo para o commit, que são realmente essas atividades:

1. Confirme as alterações locais.
2. Puxe do repositório central.
3. Mesclar (& confirmar mesclagem.)
4. Pressione para repo central.

Isso mantém a atividade de mesclagem em uma pessoa que estava trabalhando recentemente nesse código e deve poder integrar suas alterações tão rapidamente quanto qualquer outra pessoa.

Como apontado na pergunta, isso realmente apenas acrescenta esforço quando duas pessoas estão trabalhando na mesma área de código. Se for esse o caso, há mais benefícios em usar o DVCS de qualquer maneira, portanto, o retorno já é evidente para esses desenvolvedores. (Benefícios adicionais incluem cada desenvolvedor capaz de confirmar código separadamente e jogar com seu próprio repositório sem que outro desenvolvedor atrapalhe.)

Outra questão que você menciona:

Além disso, como o DVCS tende a tornar o trabalho local tão conveniente, é provável que os desenvolvedores acumulem algumas alterações em seus repositórios locais antes de enviá-los, tornando esses conflitos mais comuns e mais complicados.

Isso não cria um problema de mesclagem para nós, mas pode criar um problema diferente:

A flexibilidade do DVCS significa que muitos fluxos de trabalho diferentes são possíveis, mas alguns deles são irresponsáveis. Com o DVCS, a necessidade de processos ou procedimentos claros aumenta. A atividade de manter as mudanças locais pode ou não ser apropriada, dependendo de muitas coisas.

Por exemplo: um desenvolvedor pode trabalhar em um recurso para animais de estimação no tempo livre durante algumas semanas? Em alguns ambientes, isso é incentivado; em alguns, isso seria inadequado e todas as mudanças devem ser centralizadas em breve. Porém, se um desenvolvedor estiver mantendo alterações localmente, certamente desejará obter as alterações relacionadas para garantir que seu trabalho continue a funcionar bem com a última revisão comum.

Quando a borracha encontra a estrada, os lançamentos ou implantações de software geralmente vêm de um repositório central, portanto os desenvolvedores precisam fazer as alterações lá para teste e implantação.

Essa é a minha história, e eu vou continuar, por pelo menos alguns minutos ...

A premissa de sua pergunta parece estar em torno de "Mesclagens são difíceis e devem ser evitadas". Os sistemas DVCS removem essa barreira; na verdade, eles fazem mais, adotam a ideia de mesclar - você não deve ter medo de mesclagens e mesclar conflitos como resultado, pois, diferentemente das ferramentas centralizadas, as ferramentas DVCS a suportam por design.

Como declara a excelente resposta de Jamie F - O fluxo de trabalho do Commit-Pull-Merge-Push feito regularmente (diariamente) significa que, se você está andando em algum trabalho de outra pessoa, vê-o cedo - desde que visível, ele pode ser gerenciado .

Os problemas que você descreve são mais sobre como você escolhe usar as ferramentas.

Mudamos de SVN para GIT há 6 meses, depois de usar SVN e GIT localmente por alguns anos. Ninguém voltará, e os dolorosos conflitos de mesclagem são coisa do passado. O mantra "Commit pequeno e frequentemente" é a chave.

Quando eu trabalhei em uma equipe que usava git, a regra geral era a seguinte: trabalhe em uma filial particular; quando estiver pronto para disponibilizar seu trabalho para o restante da equipe, troque sua filial para mestre antes de pressionar. (Valide sua filial).

Essa estratégia significava que o mestre era uma série linear de confirmações e que todos os problemas de integração eram reparados nas filiais antes de serem públicos.

Uma ferramenta como o SVN incentiva fortemente uma maneira de trabalhar totalmente integrada.

Ou seja, comprometendo-se frequentemente a um ramo compartilhado (tronco ou ramo de desenvolvimento).

Isso é bom para a maioria dos ambientes de desenvolvimento corporativo que experimentei e é facilitado e incentivado ainda mais pelo uso da Integração Contínua, suportada por extensos testes de integração, testes de regressão e testes de unidade (ajudar os desenvolvedores individuais a confiarem que não quebraram qualquer coisa por suas mudanças).

O DVCS oferece a liberdade de trabalhar de forma mais independente, o que você precisa em algumas situações, e o suporte (muito elogiado) para mesclagens não pode causar nenhum dano.

A preocupação que sempre permanece no fundo da minha mente é esta: com grande liberdade vem a tentação de usar essa liberdade.

Certamente, na minha experiência (limitada), passo muito mais tempo trabalhando independentemente na minha equipe atual (usando o Mercurial) do que nas funções anteriores (onde usamos SVN, CVS e P4).

Isso é apenas parcialmente atribuído à ferramenta, mas acho que é uma observação razoável fazer que, na falta de um motivo convincente para gastar o esforço em comunicação e coordenação, as pessoas tenderão a trabalhar separadas e isoladas.

Isso não é necessariamente uma coisa ruim, mas acredito que é algo que precisa ser levado em consideração.

A coisa com o controle de versão do tipo git / mercurial é cometer frequentemente e enviar para o servidor centralizado quando o código estiver bom. Uma grande vantagem disso é que ele cria pequenos patches, que são fáceis de aplicar em casos de conflitos. Além disso, seu fluxo de trabalho deve ser algo nas linhas de:

1. Muitos commit locais
2. Puxar do servidor
3. Enviar para o servidor

Esse pull do servidor pode criar conflitos, mas para resolver isso, tudo o que é necessário muitas vezes é uma simples reformulação, em vez de uma mesclagem. Sinto que isso manterá o histórico da linha principal bastante limpo e removerá muitos conflitos.

Esse também é o caso quando você sai do repositório local de um colega de trabalho, pois duas coisas podem acontecer. Ou ele envia para o servidor primeiro, o que é bom, já que você já possui os patches dele, e nenhum conflito deve ocorrer, ou você empurra primeiro, o que significa que ele só receberá os patches quando ele puxar.

Obviamente, às vezes uma mesclagem é uma solução melhor, como um exemplo, se você estiver trabalhando em um ramo de recurso que deve ser mesclado no master.

No seu fluxo de trabalho, você está falando sobre as pessoas terem que ir explicitamente a outro desenvolvedor e dizer a ele para corrigir o conflito, mas isso não deve ser necessário. O servidor central é o "chefe" e contra o qual você deve trabalhar principalmente. Se suas alterações se aplicarem ao repositório central, você estará bem. Caso contrário, é SEU trabalho corrigir o conflito, o que pode exigir que o desenvolvedor com o qual você conflita ajude a entender suas alterações. Isso é algo que você vê quando tenta extrair / refazer o servidor. Portanto, seja feliz em se comprometer e lide com os conflitos quando precisar sair do servidor.

O princípio de trabalhar com repositório centralizado é o mesmo ao trabalhar com sistema centralizado ou distribuído sem travamento:

• No sistema centralizado você:
  1. Obtenha a versão mais recente da linha principal ("trunk" no subversion, "master" no git, ...)
  2. Modifique os arquivos
  3. Mesclar as modificações com a versão mais recente da linha principal usando o comando "update"
  4. Comprometa-se com a linha principal
• No sistema distribuído você:
  1. Obtenha a versão mais recente da linha principal
  2. Modifique os arquivos
  3. Confirme localmente
  4. Mesclar as modificações com a versão mais recente da linha principal e confirmar o resultado localmente
  5. Pressione para a linha principal.

Nenhuma versão distribuída permitirá empurrar uma revisão que não mescla completamente a revisão principal anterior (sem substituição especial; às vezes é útil); portanto, ela não será executada sem a etapa de mesclagem (portanto, não haverá duas versões para alguém). teria que consolidar como você se interessou).

Agora observe que quatro das etapas são as mesmas, exceto na terminologia, mas os sistemas distribuídos adicionam uma etapa extra "3. Confirmar localmente". A grande vantagem desta etapa é que, quando a atualização / recepção cria conflitos e você não tem certeza de como resolvê-los ou cometer um erro ao resolvê-los, você pode voltar, revisar o que fez e refazer a mesclagem. O Subversion não se lembrará de nenhum deles, portanto, se você cometer um erro ao resolver a atualização, estará ferrado.

Quanto à acumulação de mudanças, as pessoas tendem a fazer isso também com o sistema centralizado. Especialmente se você precisar alternar entre os recursos com frequência (como interromper algum trabalho mais longo para corrigir um bug ou fazer alguns ajustes que o cliente precisa urgentemente), as pessoas frequentemente precisarão manter as alterações localmente simplesmente porque elas não terminaram. Portanto, é melhor se o sistema, pelo menos, suportar dar sentido a ele.

Em ambos os casos, essas questões precisam ser tratadas por diretrizes e comunicação adequadas na equipe e não pelas ferramentas. Com ferramentas mais flexíveis, as diretrizes são mais importantes, mas as ferramentas mais flexíveis permitem lidar melhor com vários casos extremos.