Os DVCSs desencorajam a integração contínua?


34

Digamos que haja uma equipe de dez desenvolvedores ágeis. Todos os dias, cada um deles escolhe uma tarefa do quadro, comete várias alterações contra ela, até (no final do dia) concluir a tarefa. Todos os desenvolvedores fazem check-in diretamente contra o tronco (no estilo do Google, todo commit é um candidato a lançamento, usando o recurso alterna etc.).

Se eles estavam usando um CVS centralizado como o SVN, toda vez que um deles é confirmado, o servidor de compilação integrará e testará suas alterações no trabalho dos outros nove desenvolvedores. O servidor de compilação estará praticamente funcionando continuamente o dia todo.

Mas se eles estavam usando um DCVS como git, o desenvolvedor pode esperar até que eles concluam a tarefa antes de enviar todos os seus commits locais até o repositório central. Suas mudanças não serão integradas até o final do dia.

Nesse cenário, a equipe SVN está se integrando continuamente com mais frequência e descobrindo problemas de integração muito mais rapidamente que a equipe git.

Isso significa que os DVCSs são menos adequados para equipes contínuas do que as ferramentas centralizadas mais antigas? Como vocês contornam esse problema de adiamento?


15
As pessoas confirmarão pelo menos uma vez antes de concluir a tarefa ao usar o SVN? E as pessoas pressionam apenas uma vez por dia ao usar um DVCS? Seu raciocínio assume que nenhum dos dois é verdadeiro, mas minha impressão indica o contrário.

3
Muito boa pergunta.
Michael Brown

1
@ delnan: suponha que ambas as equipes se comprometam várias vezes por dia, mas os caras do git só juntam essas confirmações quando a tarefa é concluída.
Richard Dingwall

2
Eu acho que você está olhando para o lado errado do tubo, você terá problemas, não se você não forçar até concluir, mas se você não puxar regularmente durante o desenvolvimento
jk.

2
Eu já vi o contrário: os desenvolvedores que usam um sistema de controle de origem centralizado como o TFS cometem raramente, porque seu código afeta todos quando o fazem. Eles acabam salvando temporariamente seu trabalho nas prateleiras de monstros e, quando terminam, tudo ocorre em um único commit.
precisa saber é o seguinte

Respostas:


26

Disclaimer: Eu trabalho para Atlassian

O DVCS não desencoraja a Integração Contínua, desde que o desenvolvedor envie remotamente regularmente para sua própria filial e o servidor de CI esteja configurado para criar as ramificações ativas conhecidas.

Tradicionalmente, existem dois problemas com DVCS e CI:

  • Incerteza do estado de integração - a menos que o desenvolvedor esteja mesclando regularmente do mestre e executando a construção, você não sabe qual é o estado das alterações combinadas. Se o desenvolvedor precisar fazer isso manualmente, é provável que isso não seja feito com frequência suficiente para detectar problemas com antecedência.
  • Duplicação e desvio da configuração da compilação - se a configuração da compilação precisar ser copiada de uma compilação 'master' para criar uma compilação de ramificação, a configuração da ramificação poderá rapidamente ficar fora de sincronia com a compilação da qual foi copiada.

No Bamboo, introduzimos a capacidade do servidor de compilação de detectar novas ramificações conforme elas são criadas pelos desenvolvedores e configurar automaticamente as compilações para a ramificação com base na configuração de compilação do master (portanto, se você alterar a configuração de master masters, ela também mudará a configuração de ramificações). para refletir a mudança).

Também temos um recurso chamado Estratégias de mesclagem que pode ser usado para atualizar a ramificação com alterações do mestre antes que a compilação da ramificação seja executada ou enviar automaticamente as alterações em uma ramificação de compilação bem-sucedida para mestre, garantindo que as alterações entre ramificações sejam testadas juntas o mais rápido possível .

De qualquer forma, se você estiver interessado em aprender mais, consulte minha postagem no blog "Tornando as ramificações de recursos eficazes com a integração contínua"


14

Minha pequena equipe mudou para um DVCS há um ou dois anos e o resto da minha empresa seguiu o exemplo alguns meses atrás. Em minha experiência:

  • As pessoas que usam um VCS centralizado ainda tendem a adiar as confirmações quando estão realizando um grande projeto. Este não é um problema exclusivo dos DVCSes. Eles terão conjuntos de alterações que aguardam vários dias antes de fazer um commit. A grande diferença é que, se eles cometerem algum erro durante esse período, ou se o computador travar, será necessário muito mais esforço para corrigi-lo.
  • Usamos um fluxo de trabalho de confirmação em que cada desenvolvedor trabalha em sua própria ramificação nomeada, e somente a pessoa que revisou seu código pode mesclar suas alterações na cabeça. Isso reduz a probabilidade de uma confirmação causar problemas, para que as pessoas prestem atenção quando o servidor de compilação produzir uma mensagem de erro. Isso também significa que outros desenvolvedores podem continuar trabalhando em suas próprias ramificações até que a cabeça seja corrigida.
  • Em um DVCS, as pessoas tendem a gastar mais tempo programando antes de mesclar seu código com a cabeça. Portanto, ele tende a introduzir um pequeno atraso na continuidade da compilação. Mas a diferença não é significativa o suficiente para contrariar as vantagens do DVCS.

O servidor de compilação cria todas as ramificações nomeadas para que cada committer tenha seu próprio trabalho de servidor de compilação?

O revisor de código não se torna um gargalo sério nesse cenário?
Andrés F.

@ ThorbjørnRavnAndersen: Não, o servidor de compilação cria apenas a ramificação "head" ou "default" e as ramificações de liberação. Portanto, cada usuário pode se comprometer com sua própria ramificação nomeada sem medo de quebrar a compilação. É possível conceber configurar um servidor de compilação para compilar as ramificações de todos, mas em alguns casos eu quero comprometer algum trabalho que fiz, sabendo muito bem que isso coloca minha própria ramificação em um estado inutilizável. Vou garantir que minha ramificação esteja estável antes de fazer uma revisão e mesclar o código. Eu só me importo que os principais ramos que todo mundo usa sejam estáveis.
StriplingWarrior

@AndresF .: Não, não se tornou um gargalo sério para nós. Por um lado, temos várias pessoas que podem fazer revisões de código; portanto, cada desenvolvedor geralmente encontra pelo menos um revisor que está disponível para revisão a qualquer momento. Além disso, parte da beleza de um DVCS é que, mesmo que não seja possível mesclar imediatamente, você pode começar a trabalhar em outra coisa, e outros desenvolvedores podem mesclar suas alterações em suas ramificações, se dependerem das alterações para o trabalho deles. Uma vez que o código é revisado, há um nó específico de alterações que o revisor pode mesclar no.
StriplingWarrior

13

Recentemente, observei cerca de 19 projetos que usavam o Mercurial over SubVersion (eu era um nerd do subversion ): os desenvolvedores começaram a se tornar realmente individualistas trabalhando em sua própria filial e integrando-se apenas após dias ou semanas de servidor. Isso causou sérios problemas e preocupações de integração.

Outro problema que enfrentamos é com o servidor de integração contínua. Fomos notificados de problemas (falha no teste, por exemplo), somente quando a sincronização de confirmações foi feita no servidor.

Parece que Martin Fowler escreveu sobre isso em seu site.

Dito isto, alguns dos projetos que mencionei fizeram uma sincronização pelo menos uma vez ao dia, reduzindo os problemas. Então, para responder sua pergunta, acho que o DVCS pode desencorajar a integração contínua e aumentar o individualismo. No entanto, o DVCS não é a causa direta.

O desenvolvedor ainda está no comando, independentemente do VCS que eles usam.


Os projetos mencionados enfatizaram um objetivo comum ou os desenvolvedores tiveram que trabalhar em metas específicas e desconectadas?

Não podemos generalizar em 19 projetos. Mas quando enfrentamos problemas de integração, isso também ocorre porque alguns princípios, como separação de preocupações, não foram respeitados. O que digo é que sim, o DVCS parece incentivar o individualismo e reduzir os benefícios da integração contínua, mas, se os desenvolvedores forem bem treinados, é possível reduzir ou eliminar o problema.

Nesse caso, sugiro que você também faça entregas contínuas, ou pelo menos entregas freqüentes de clientes, portanto o prazo para quando a fusão DEVE ocorrer é muito menor. Você fez isso nesses projetos?

Obviamente, usamos Scrum

1
Eu estava procurando por sua definição de entrega contínua (ainda não conseguiu encontrar algo decente, vou apreciar se você poderia me dar algumas referências), e encontrei este: continuousdelivery.com/2011/07/...

10

A idéia na qual você baseia seu raciocínio é muito instável, em voz baixa. É o problema da equipe / gerenciamento / processo que o desenvolvedor pode esperar até concluir a tarefa .

Fazer isso de uma maneira ou de outra, "espera" ou "pressa", tronco compartilhado ou ramificação isolada, é conhecido como estratégia de ramificação e, se você estudar as informações disponíveis on-line , descobrirá que escolher uma estratégia específica basicamente não tem nada a ver com VCS sendo centralizado ou distribuído.

Digamos, para VCS distribuídos como o Mercurial, você pode facilmente encontrar recomendações fortes para fusões frequentes :

Primeiro, mesclar frequentemente! Isso facilita a fusão para todos e você descobre conflitos (que geralmente estão enraizados em decisões de design incompatíveis) antes ...

Estudando as recomendações acima, pode-se descobrir com facilidade que elas atraem considerações que nada têm a ver com a distribuição do Mercurial.

Agora, vejamos a situação ao lado do VSC centralizado, o Subversion. Estudando informações on-line, pode-se encontrar entre as principais estratégias populares, chamadas tronco estável e tronco instável - cada uma tendo impacto oposto na frequência de fusões. Veja bem, as pessoas escolhem uma ou outra maneira de fazer as coisas sem prestar atenção ao VCS sendo centralizado.

  • Eu vi fusões severamente atrasadas acontecendo (mesmo incentivadas pelo gerenciamento coxo) com o VCS centralizado, bem como fusões freqüentes feitas com o DVCS quando a equipe / gerência achou que era o caminho certo. Vi que ninguém se importa se o VCS é distribuído ou centralizado na decisão de uma maneira ou de outra.

Dado acima, parece a resposta certa para os DVCSs desencorajarem a integração contínua? seria Mu .

O VCS sendo distribuído ou não não tem um impacto substancial nisso.


1
+1 Concordo com você que o gerenciamento é a chave para resolver o problema. No entanto, devemos admitir que algo no DVCS que desencoraja a integração contínua. De fato, uma das principais características do DCVS incentiva esse comportamento.

1
@ Pierre303 talvez - eu também me sinta assim, mas isso é basicamente uma teoria. Como escrevi, vi equipes integrando loucamente ao DVCS e, por outro lado, o projeto mais "isolacionista" em que já trabalhei (e isso foi um pesadelo) foi com o VCS centralizado. Tanto para os sentimentos, tanto para a teoria ...
mosquito

Admito que é apenas uma observação empírica, mas em um grande número de projetos, e provavelmente há um grande viés de "habilidade" envolvido.

10

Minha experiência é exatamente o oposto : as equipes que usam svn não pressionavam por dias, porque o código em que estavam trabalhando faria com que o tronco não fosse compilado para todos os outros sem perder tempo com a fusão manual. Então, perto do final do sprint, todos se comprometiam, a loucura se misturava, as coisas sobrescreviam e se perdiam e precisavam ser recuperadas. O sistema de CI ficaria em VERMELHO e a indicação de dedo seria seguida.

Nunca tive esse problema com o Git / Gitorious.

O Git permite puxar e mesclar mudanças de outras pessoas conforme sua conveniência, não porque alguém tenha verificado algo e você queira fazer o check-in, mas você tem 20 minutos de mesclagem manual para fazer.

O Git também permite extrair os commits de todos os outros, mesclar seu código e enviar uma versão funcional para todos, para que eles não precisem adivinhar o que devem ser mesclados com base no que você mudou.

Ter algo como Gitorious como mediador de revisões de código por meio de solicitações de mesclagem torna o gerenciamento de muitos ramos e muitos colaboradores muito simples.

Configurar o Jenkins / Hudson para rastrear todas as ramificações ativas em um repositório Git também é muito fácil. Tivemos mais tração com o CI e feedback mais frequente sobre o estado dos repositórios quando nos mudamos para o SVN para o Git.


por que eles se comprometeriam diretamente com o tronco? Eu acho que esse foi seu problema.
Gbjbaanb

1
@gbjbaanb, porque essa é a maneira tradicional de trabalhar no CVS idiomático, porque esse é o idioma tradicional do repositório centralizado. Os usuários do SVN geralmente são ex-usuários do CVS, e ramificar e mesclar no SVN é apenas marginalmente melhor do que no CVS; que foi além do doloroso / quase impossível de corrigir. Este é o caso de 99% do fluxo de trabalho em 99% de todas as lojas SVN, devido às ferramentas e ao pensamento do grupo.

@JarrodRoberson: absurdo. Meus antigos usuários do SVN eram refugiados do VSS :) A fusão no SVN não é tão ruim quanto você pensa. Nesse caso, ele reclama que seus usuários quebrariam a compilação verificando código quebrado diretamente no tronco - e, em seguida, ter que mesclar, francamente, ter que mesclar seu código com o do seu colega não é algo opcional, se você estiver trabalhando diretamente no o mesmo ramo.
Gbjbaanb

4

Servidores de construção são baratos. Basta fazer com que o servidor de CI selecione todas as filiais que você conhece.

O Jenkins tem suporte para verificar vários repositórios git e obter o 'mais recente' de qualquer um em um único trabalho. Tenho certeza de que existem soluções semelhantes com outras ferramentas.


E o que acontece se você deseja comprometer algo que quebra, headmas ajuda um colega ou é necessário para que um colega possa ajudá-lo? Você pode criar um diff e enviar por e-mail ao seu colega, mas de alguma forma isso não parece certo.
Arjan

1
Ramo da equipe / recurso? Ou puxar diretamente do seu repositório de colegas? Se mais de uma pessoa estiver trabalhando em algo que iria quebrar a cabeça, mas ainda exigir uma confirmação de linha do tempo / estágios múltiplos, ela merece seu ramo de recurso / trabalho de qualquer maneira. Entre na cabeça quando estiver pronto.
Ptyx 17/05/12

Uma ramificação de equipe da ramificação de recursos não funcionará se sua ferramenta de IC selecionar todas as ramificações que você conhece. E se sua ferramenta de IC também processar vários repositórios, você ainda não deseja incluir repositórios de desenvolvedor, apenas porque eles podem não ter sido totalmente testados.
Arjan

1
O servidor de IC não saberá automaticamente de uma ramificação privada até que seja informado sobre isso. Cabe aos indivíduos escolherem se desejam suas filiais no IC ou não. (Não existe solução milagre)
ptyx

Portanto, o CI não deve selecionar todos os ramos que você conhece, mas apenas aqueles que você deseja no CI. Para mim isso é uma diferença. Ainda assim, eu acho que eu entendo o que você está tentando dizer, então +1
Arjan

4

Essa pergunta antiga acabou de ser marcada como duplicada de uma nova e, como muitas das respostas fazem referência a algumas idéias desatualizadas, pensei em publicar uma atualizada.

Uma coisa que aparentemente não era muito comum há cinco anos foi a execução de testes de IC nas ramificações de solicitação pull antes de mesclá-las no mestre. Eu acho que isso reflete uma atitude de mudança que, apesar de mesclar com frequência é desejável, compartilhar todas as mudanças com todos , assim que você as realiza, não é ideal.

O DVCS gerou um modo mais hierárquico de integrar seus commits. Por exemplo, muitas vezes trabalho em tarefas muito próximas ao desenvolvedor que está sentado ao meu lado. Puxaremos dos galhos um do outro várias vezes por dia. Hoje, colaboramos com outro desenvolvedor por meio de alterações enviadas a uma solicitação pull a cada poucas horas.

Estávamos fazendo grandes alterações nos scripts de construção. O Jenkins mescla localmente todas as ramificações de relações públicas com o mestre e executa testes, por isso recebemos feedback automatizado dessa maneira, sem perturbar qualquer outro desenvolvedor que precisava de uma construção limpa. Provavelmente levará mais um dia para que o PR esteja pronto para mesclar para dominar e compartilhar fora do nosso grupo de três desenvolvedores.

No entanto, se alguém mal puder esperar que nossas alterações sejam dominadas, porque a mudança depende da nossa, ele poderá mesclar nosso ramo de desenvolvimento localmente e continuar com seu trabalho. É disso que muitas pessoas acostumadas ao CVCS sentem falta. Com o CVCS, a única maneira de compartilhar suas alterações é mesclá-las ao repositório central, e é por isso que a fusão geralmente é mais crítica. Com o DVCS, você tem outras opções.


3

Eu diria que o DVCS é mais propício à integração contínua. Mesclagens não são tão irritantes com elas. No entanto, requer mais disciplina. Você deve seguir uma confirmação local com um puxão da base para mesclar e pressionar quando sua tarefa estiver concluída (antes de ir para a próxima).


2

Quando minha equipe mudou para o Git, explicitamente definimos nosso processo de forma que um push fosse tratado exatamente como um commit no VCS mais antigo, e os commits locais poderiam ser feitos com a frequência / pouca frequência que cada indivíduo escolheu. Com isso, não há diferença para o sistema de IC se estamos usando um DVCS ou um VCS centralizado.


1

A resposta é sim e não, simultaneamente.

A diferença aqui é entre confirmar diretamente no repositório central visualizado por IC e enviar suas alterações para o repositório central visualizado por IC. O 'problema' que você pode encontrar é que os usuários do DVCS podem não executar esse push regularmente.

Eu diria que esse é um recurso de design inerente de um DVCS; ele não foi projetado para enviar suas alterações ao servidor central o tempo todo - se fosse, você também poderia usar um CVCS. Portanto, a resposta é reforçar um fluxo de trabalho melhor entre seus desenvolvedores. Diga a eles para fazer alterações todas as noites. Simples!

(e se os usuários do seu SVN não estiverem se comprometendo todas as noites, peça para eles - é exatamente o mesmo problema).


0

O Git não está impedindo a integração contínua. Seu fluxo de trabalho baseado em tronco é.

Isso pode parecer contra-intuitivo, mas: se os desenvolvedores trabalham em ramificações de recursos, podem ser incentivados a integrar-se frequentemente em suas próprias máquinas (e isso é necessário antes de enviar seu recurso para mesclagem). Por outro lado, um fluxo de trabalho baseado em tronco favorece confirmações maiores e, portanto, menos integração freqüente.

Eu mantenho que um fluxo de trabalho baseado em tronco no estilo do Google é contraproducente com um VCS como o Git, onde a fusão é fácil. Aqui está o que eu recomendaria:

  • Divida os recursos em um tamanho suficientemente pequeno para que nenhum deles demore mais de um dia ou dois para se desenvolver.
  • Cada recurso é desenvolvido em uma ramificação privada.
  • O desenvolvedor integra-se frequentemente no ramo privado ( git fetch origin; git merge master). Normalmente, faço isso várias vezes ao dia quando trabalho dessa maneira.
  • Quando o desenvolvedor envia uma ramificação para mesclagem e revisão, o servidor de CI faz uma compilação automatizada. A mesclagem só acontece quando isso passa.

Então, você tem: confirmações pequenas, integração frequente e um histórico rastreável do que pertencia a qual recurso. Ramos, usados ​​corretamente, são a chave para tudo o que vale a pena no Git, portanto, evitá-los é um grande erro.


-1

Existem soluções técnicas incríveis como @jdunay mencionadas, mas para nós é uma questão de pessoas - da mesma maneira que promover um ambiente em que as pessoas se comprometem com o svn geralmente é uma questão de pessoas.

O que funcionou para nós é: (substitua 'master' pelo ramo de desenvolvimento atualmente ativo)

  1. Mesclagens / rebotes frequentes do mestre
  2. Pressões suficientes para dominar
  3. Consciência das coisas que causam o inferno, como certas refatorações, e mitigação disso através da comunicação. Por exemplo:

    • Certifique-se de que todos empurram antes do almoço
    • Realize e empurre a refatoração durante o almoço
    • Certifique-se de que todos puxem depois do almoço
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.