Les DVCS découragent-ils l'intégration continue?

34

Disons qu'il existe une équipe de dix développeurs agiles. Chaque jour, ils choisissent chacun une tâche sur le tableau et y apportent plusieurs modifications jusqu'à ce qu'ils aient terminé (à la fin de la journée). Tous les développeurs se connectent directement à trunk (à la manière de Google, chaque commit est une release candidate, utilisation de la fonctionnalité bascule, etc.).

S'ils utilisaient un CVS centralisé tel que SVN, chaque fois que l'un d'eux se valide, le serveur de construction intégrera et testera leurs modifications par rapport au travail des neuf autres développeurs. Le serveur de compilation fonctionnera quasiment toute la journée.

Mais s’ils utilisaient un DCVS tel que git, le développeur peut attendre jusqu’à ce qu’il ait terminé la tâche avant de regrouper tous ses commits locaux dans le référentiel central. Leurs changements ne seront pas intégrés avant la fin de la journée.

Dans ce scénario, l’équipe SVN s’intègre de plus en plus fréquemment et découvre les problèmes d’intégration beaucoup plus rapidement que l’équipe git.

Cela signifie-t-il que les DVCS conviennent moins aux équipes continues que les anciens outils centralisés? Comment pouvez-vous résoudre ce problème de report différé?

Richard Dingwall
la source
15
Les personnes s'engageront-elles au moins une fois avant la fin de la tâche lors de l'utilisation de SVN? Et les gens ne pousseront-ils qu'une fois par jour lorsqu'ils utiliseront un DVCS? Votre raisonnement suppose que ni est vrai, mais mon impression indique le contraire.
3
Très bonne question.
Michael Brown
1
@delnan: supposons que les deux équipes se commettent plusieurs fois par jour, mais que les gars git ne poussent ces commits que lorsque la tâche est terminée.
Richard Dingwall
2
Je pense que vous regardez du mauvais côté du tuyau, vous avez des problèmes, pas si vous ne poussez pas complètement, mais si vous ne tirez pas régulièrement pendant le développement
jk.
2
J'ai vu le contraire: les développeurs utilisant un système de contrôle de source centralisé comme TFS commit rarement, car leur code affecte tout le monde quand ils le font. Ils finissent par sauvegarder temporairement leur travail sur des étagères de monstres et, une fois leur travail terminé, tout est intégré dans un commit monstre.
Kyralessa

Réponses:

26

Disclaimer: Je travaille pour Atlassian

DVCS ne décourage pas l'intégration continue tant que le développeur envoie régulièrement à distance son propre site et que le serveur CI est configuré de manière à créer les branches actives connues.

Il existe traditionnellement deux problèmes avec DVCS et CI:

  • Incertitude de l'état d'intégration - à moins que le développeur ne fusionne régulièrement depuis maître et exécute la construction, vous ne savez pas quel est l'état des modifications combinées. Si le développeur doit le faire manuellement, il est probable que cela ne sera pas fait assez souvent pour résoudre les problèmes suffisamment tôt.
  • Duplication et dérive de la configuration de construction : si la configuration de construction doit être copiée à partir d'une construction "principale" pour créer une construction de branche, la configuration de la branche peut rapidement devenir désynchronisée par rapport à la construction à partir de laquelle elle a été copiée.

En Bamboo, nous avons introduit la possibilité pour le serveur de génération de détecter les nouvelles branches créées par les développeurs et de configurer automatiquement les générations pour la branche en fonction de la configuration de construction du maître (si vous modifiez la configuration de construction principale, elle modifie également la configuration de branche). refléter le changement).

Nous avons également une fonctionnalité appelée Stratégies de fusion qui peut être utilisée pour mettre à jour la branche avec les modifications apportées par le maître avant l'exécution de la génération de branche, ou pour pousser automatiquement les modifications d'une branche de construction réussie vers le maître, en s'assurant que les modifications entre les branches sont testées ensemble dès que possible. .

Quoi qu'il en soit, si vous souhaitez en savoir plus, consultez mon article de blogue "Rendre efficaces les branches de fonctionnalité avec l'intégration continue".

jdumay
la source
14

Ma petite équipe est passée à un système DVCS il y a un an ou deux, et le reste de mon entreprise a emboîté le pas il y a deux mois. Dans mon expérience:

  • Les personnes utilisant un système de contrôle centralisé (VCS) centralisé ont toujours tendance à retarder les validations lorsqu'elles réalisent un projet volumineux. Ce n'est pas un problème unique aux DVCS. Ils auront des jeux de modifications qui attendent plusieurs jours avant de faire un commit. La grande différence est que s’ils commettent une erreur à un moment donné ou que l’ordinateur tombe en panne, il faudra beaucoup plus d’efforts pour y remédier.
  • Nous utilisons un flux de travail de validation dans lequel chaque développeur travaille sur sa propre branche nommée, et seule la personne qui a examiné son code est autorisée à fusionner ses modifications dans la tête. Cela réduit la probabilité qu'un commit provoque des problèmes, ainsi les utilisateurs sont vraiment attentifs lorsque le serveur de génération génère un message d'erreur. Cela signifie également que d'autres développeurs peuvent continuer à travailler sur leurs propres branches jusqu'à ce que la tête soit réparée.
  • Sur un DVCS, les gens ont tendance à passer plus de temps à programmer avant de fusionner leur code avec la tête. Cela tend donc à introduire un peu de retard dans la continuité de la construction. Mais la différence n'est pas assez importante pour contrer les avantages du DVCS.
StriplingWarrior
la source
Le serveur de construction construit toutes les branches nommées afin que chaque responsable ait son propre travail de serveur de construction?
L'examinateur de code ne devient-il pas un grave goulot d'étranglement dans ce scénario?
Andres F.
@ ThorbjørnRavnAndersen: Non, le serveur de construction ne construit que la branche "tête" ou "par défaut" et les branches de version. Ainsi, chaque utilisateur peut s’engager dans sa propre branche nommée sans craindre de rompre la construction. Nous pourrions concevoir un serveur de build pour créer les branches de tout le monde, mais dans certains cas, je veux engager le travail que j'ai effectué, sachant pertinemment que cela met ma propre branche dans un état inutilisable. Je vais m'assurer que ma branche est stable avant de réviser et de fusionner le code. Je me soucie seulement que les branches principales que tout le monde utilise sont stables.
StriplingWarrior
@AndresF: Non, cela ne nous a pas posé de problème sérieux. D'une part, nous avons plusieurs personnes qui peuvent effectuer des révisions de code, de sorte que chaque développeur peut généralement trouver au moins un relecteur disponible pour une révision à un moment donné. En outre, l'un des avantages d'un système DVCS réside dans le fait que même si vous ne pouvez pas fusionner tout de suite, vous pouvez commencer à travailler sur autre chose et permettre aux autres développeurs de fusionner vos modifications dans leurs branches si elles dépendent de vos modifications pour leur travail. Une fois votre code révisé, le réviseur peut fusionner avec un noeud de jeu de modifications spécifique.
StriplingWarrior
13

J'ai récemment observé environ 19 projets utilisant Mercurial sur SubVersion (j'étais un geek de la subversion ): les développeurs ont commencé à devenir vraiment individualistes en travaillant sur leur propre branche et en s'intégrant seulement après plusieurs jours ou semaines. Cela a causé de graves problèmes d'intégration.

Un autre problème que nous avons rencontré est avec le serveur d'intégration continue. Nous avons été informés des problèmes (test ayant échoué, par exemple) uniquement lorsque la synchronisation des validations a été effectuée sur le serveur.

Il semble que Martin Fowler en ait parlé sur son site.

Cela dit, une partie du projet que j'ai mentionné a effectué une synchronisation au moins une fois par jour, réduisant ainsi les problèmes. Donc, pour répondre à votre question, je pense que DVCS peut décourager l'intégration continue et accroître l'individualisme. Cependant, DVCS n'est pas la cause directe.

Le développeur est toujours responsable quel que soit le VCS utilisé.

Communauté
la source
Ces projets ont-ils mis l'accent sur un objectif commun ou les développeurs ont-ils dû travailler sur des cibles spécifiques, déconnectées?
Nous ne pouvons pas généraliser sur 19 projets. Mais lorsque nous avons été confrontés à des problèmes d'intégration, c'est aussi parce que certains principes tels que la séparation des préoccupations n'étaient pas respectés. Ce que je dis, c’est que, oui, DVCS semble encourager l’ individualisme et réduire les avantages de l’intégration continue, mais si les développeurs sont bien formés, il est possible de réduire ou d’éliminer le problème.
Dans ce cas, je suggérerais que vous effectuiez également des livraisons continues, ou du moins des livraisons fréquentes aux clients, afin que le délai pour la fusion DOIT avoir lieu est beaucoup plus court. L'avez-vous fait dans ces projets?
Bien sûr, nous utilisons Scrum
1
Je cherchais votre définition de livraison continue (vous ne trouvez toujours pas quelque chose de convenable, je vous
10

L'idée sur laquelle vous basez votre raisonnement est très fragile, à parler doucement. C'est une question d'équipe / de gestion / de processus que le développeur peut attendre jusqu'à ce qu'il ait terminé la tâche .

Le faire d'une manière ou d'une autre, "attendre" ou "presser", tronc partagé ou branche isolée, est connu sous le nom de stratégie de branchement . Si vous étudiez les informations disponibles en ligne , vous découvrirez que le choix d'une stratégie en particulier n'a fondamentalement rien à voir avec VCS étant centralisé ou distribué.

Par exemple, pour les VCS distribués comme Mercurial, vous pouvez facilement trouver des recommandations fortes pour les fusions fréquentes :

Tout d'abord, fusionnez souvent! Cela facilite la fusion pour tout le monde et vous permet de connaître les conflits (souvent liés à des décisions de conception incompatibles) plus tôt ...

En étudiant les recommandations comme ci-dessus, on peut facilement découvrir que cela fait appel à des considérations n’ayant rien à voir avec la distribution de Mercurial.

Maintenant, regardons la situation à côté de VSC centralisé, Subversion. En étudiant les informations en ligne, on peut trouver parmi les stratégies les plus populaires ce qu’on appelle le tronc stable et le tronc instable - chacune ayant un impact opposé sur la fréquence des fusions. Vous voyez, les gens choisissent l'une ou l'autre manière de faire les choses sans même prêter attention à la centralisation de VCS.

  • J'ai constaté des fusions fortement retardées (même encouragées par une gestion boiteuse) avec le VCS centralisé, ainsi que des fusions fréquentes avec DVCS lorsque l'équipe / la direction pensait que c'était la bonne façon. J'ai vu que personne ne se souciait de savoir si VCS était distribué ou centralisé pour décider d'une manière ou d'une autre.

Compte tenu de ce qui précède, il semble que la bonne réponse à donner aux DVCS décourage l'intégration continue. serait Mu .

Le VCS distribué ou non n’a pas d’impact significatif sur cela.

moucheron
la source
1
+1 Je conviens avec vous que la gestion est la clé pour résoudre le problème. Cependant, il faut admettre que il y a quelque chose dans DVCS qui dissuade l' intégration continue. En fait, l’un des éléments clés de DCVS encourage ce comportement.
1
@ Pierre303 peut-être - je me sens aussi comme ça, mais c'est à peu près une théorie. Comme je l'ai écrit, j'ai vu une équipe s'intégrer comme une folle avec DVCS et, d'autre part, le projet le plus "isolationniste" dans lequel j'ai jamais travaillé (et c'était un cauchemar) était avec VCS centralisé. Tant pis pour les sentiments, tant pis pour la théorie ...
tranche
Je reconnais que ce n’est qu’une observation empirique, mais sur un grand nombre de projets et qu’il existe probablement un énorme biais de «compétence».
10

Mon expérience est exactement l'inverse : les équipes utilisant svn ne poussent pas pendant plusieurs jours, car le code sur lequel elles travaillaient empêcherait le tronc de se compiler pour tout le monde sans perdre de temps en fusion manuelle. Puis, vers la fin du sprint, tout le monde s'engagerait, la folie se fusionnerait, les choses seraient écrasées et perdues et il faudrait les récupérer. Le système CI passerait au ROUGE et un doigt se serait créé.

Jamais eu ce problème avec Git / Gitorious.

Git vous permet d'extraire et de fusionner les modifications des autres peuples à votre convenance, non pas parce que quelqu'un d'autre a coché quelque chose et que vous souhaitez enregistrer, mais que vous avez 20 minutes de fusion manuelle à effectuer.

Git vous permet également d'extraire les commits de tous les autres, de fusionner votre code, puis de transmettre une version opérationnelle à tous les autres pour qu'ils n'aient pas à deviner ce qu'ils devraient fusionner en fonction de ce que vous avez modifié.

Avoir quelque chose comme Gitorious en tant que médiateur pour les révisions de code via des demandes de fusion rend la gestion de nombreuses branches et de nombreux contributeurs très facile.

Configurer Jenkins / Hudson pour suivre toutes les branches actives dans un référentiel Git est également très simple. Nous avons eu plus de traction avec CI et des commentaires plus fréquents sur l'état des référentiels lorsque nous sommes passés de SVN à Git.


la source
pourquoi s'engageraient-ils directement dans le coffre? Je pense que c'était ton problème.
gbjbaanb
1
@gbjbaanb parce que c’est la méthode de travail CVS idiomatique traditionnelle, parce que c’est l’idiome traditionnel des pensions livrées centralisées. Les utilisateurs de SVN sont généralement d'anciens utilisateurs de CVS, et la création de branches et la fusion dans SVN ne sont que légèrement meilleures que dans CVS; ce qui était au-delà douloureux / presque impossible à obtenir correct. Ceci est le cas de flux de travail de 99% dans 99% de tous les magasins SVN en raison des outils et de la pensée du groupe.
@ JarrodRoberson: un non-sens. Mes anciens utilisateurs de SVN étaient des réfugiés de VSS :) La fusion de SVN n’est pas aussi mauvaise que vous le pensez. Dans ce cas, il se plaint que ses utilisateurs briseraient la construction en archivant directement le code erroné dans le tronc - et qu'il serait alors obligé de fusionner, franchement, devoir fusionner votre code avec celui de votre collègue n'est pas une option si vous travaillez tous directement. la même branche.
gbjbaanb
4

Les serveurs de construction ne coûtent pas cher. Demandez à votre serveur CI de récupérer toutes les branches que vous connaissez.

Jenkins a le soutien nécessaire pour vérifier plusieurs référentiels git et obtenir les "derniers" de ceux-ci dans un seul travail. Je suis sûr qu'il existe des solutions similaires avec d'autres outils.

ptyx
la source
Et que se passe-t-il si vous voulez commettre quelque chose qui casse headmais aide un collègue ou est requis pour qu'un collègue puisse vous aider? Vous pouvez créer un diff et envoyer un e-mail à votre collègue, mais d'une manière ou d'une autre, cela ne vous convient pas.
Arjan
1
Équipe / branche de fonctionnalité? Ou tirage direct de votre référentiel de collègues? Si plusieurs personnes travaillent sur quelque chose qui pourrait casser la tête, mais qui nécessite tout de même une validation chronologique / à étapes, il mérite quand même sa branche fonction / travail. Fusionner pour aller quand c'est prêt.
ptyx
Une branche d'équipe d'une branche fonctionnelle ne fonctionnera pas si votre outil de CI récupère toutes les branches que vous connaissez. Et si votre outil de CI traite également plusieurs référentiels, vous ne souhaitez toujours pas inclure les référentiels de développeur, simplement parce qu'ils n'ont peut-être pas été entièrement testés.
Arjan
1
Le serveur CI ne saura pas automatiquement l'existence d'une branche privée jusqu'à ce qu'il en soit informé. C'est aux individus de choisir s'ils veulent ou non leurs succursales sur CI. (Il n'y a pas de solution miracle)
ptyx
Donc, CI ne devrait pas aller chercher toutes les branches que vous connaissez, mais seulement celles que vous voulez dans CI. Pour moi, c'est une différence. Pourtant, je pense comprendre ce que vous essayez de dire, alors +1
Arjan
4

Cette vieille question vient d'être marquée comme une copie d'une nouvelle, et comme beaucoup de réponses font référence à des idées dépassées, j'ai pensé en poster une mise à jour.

Une chose qui n’était apparemment pas très commune il ya cinq ans a été d’exécuter des tests de CI sur des branches de demandes d’extraction avant de les fusionner en maîtres. Je pense que cela reflète une attitude changeante: bien que fusionner fréquemment soit souhaitable, partager chaque changement avec tout le monde , dès que vous le faites , n'est pas optimal.

DVCS a créé un mode plus hiérarchique d’intégration de vos commits. Par exemple, je travaille souvent très étroitement avec le développeur assis à côté de moi. Nous allons nous tirer les uns des autres plusieurs fois par jour. Aujourd'hui, nous avons collaboré avec un autre développeur via des modifications poussées vers une demande d'extraction toutes les quelques heures.

Nous apportions des modifications importantes aux scripts de construction. Jenkins fusionne localement chaque branche de relations publiques avec le maître et exécute des tests. Nous avons donc obtenu des informations automatisées de cette manière, sans déranger aucun autre développeur ayant besoin d'une version propre. Il faudra probablement environ un jour ou deux avant que le RP soit prêt à être fusionné pour être maîtrisé et partagé en dehors de notre groupe de trois développeurs.

Cependant, si quelqu'un ne peut pas attendre que nos modifications fusionnent pour être maîtrisées, car leur changement dépend des nôtres, elles peuvent fusionner notre branche de développement localement et poursuivre leur travail. C'est ce que manquent beaucoup de gens habitués au CVCS. Avec CVCS, le seul moyen de partager vos modifications est de les fusionner dans le référentiel central. C’est pourquoi la fusion est souvent plus critique. Avec DVCS, vous avez d'autres options.

Karl Bielefeldt
la source
3

Je dirais que le DVCS est plus propice à l'intégration continue. Les fusions ne sont pas aussi irritantes pour elles. Cela nécessite cependant plus de discipline. Vous devez suivre un commit local avec une extraction de la base à fusionner, puis appuyer sur lorsque votre tâche est terminée (avant de passer à la suivante).

Michael Brown
la source
2

Lorsque mon équipe est passée à Git, nous avons explicitement défini notre processus de sorte qu'un push devait être traité exactement comme un commit dans l'ancien VCS, et que des commits locaux pouvaient être effectués aussi souvent / rarement que le souhaitait chaque utilisateur. Avec cela, il n'y a aucune différence entre le système CI et l'utilisation d'un DVCS ou d'un VCS centralisé.

Dan Lyons
la source
1

La réponse est à la fois oui et non.

La différence ici consiste à s’engager directement dans le référentiel central visualisé par CI et à appliquer vos modifications au référentiel central visualisé par CI. Le «problème» que vous pourriez rencontrer est que les utilisateurs de DVCS peuvent ne pas effectuer ce push régulièrement.

Je dirais que ceci est une caractéristique de conception inhérente à un système DVCS, il n'est pas conçu pour appliquer constamment vos modifications au serveur central. Si tel était le cas, vous pourriez aussi bien utiliser un CVCS. La solution consiste donc à mettre en place un meilleur flux de travail parmi vos développeurs. Dites-leur de pousser les changements chaque nuit. Simples!

(et si vos utilisateurs SVN ne s'engagent pas toutes les nuits, dites-leur - c'est exactement le même problème).

gbjbaanb
la source
0

Git n'empêche pas l'intégration continue. Votre flux de travail basé sur le coffre est.

Cela peut sembler paradoxal, mais si les développeurs travaillent sur des branches de fonctionnalités, ils peuvent être encouragés à s’intégrer fréquemment sur leurs propres machines (et doivent le faire avant de soumettre leur fonctionnalité de fusion). En revanche, un flux de travail basé sur le tronc favorise les validations plus importantes et donc une intégration moins fréquente.

Je maintiens qu'un flux de travail basé sur le style de style Google est contre-productif avec un VCS tel que Git où la fusion est facile. Voici ce que je conseillerais à la place:

  • Décomposez suffisamment les fonctionnalités pour qu’aucune d’entre elles ne prenne plus d’un jour ou deux à se développer.
  • Chaque fonctionnalité est développée sur une branche privée.
  • Le développeur s’intègre fréquemment sur une branche privée ( git fetch origin; git merge master). Je le fais généralement plusieurs fois par jour lorsque je travaille de cette façon.
  • Lorsque le développeur soumet une branche à la fusion et à la révision, le serveur CI effectue une construction automatisée. La fusion ne se produit que lorsque cela passe.

Vous avez donc cela: de petits commits, une intégration fréquente et un historique traçable de ce que les commits ont appartenu à quelle caractéristique. Les branches, utilisées correctement, sont la clé de tout ce qui vaut la peine chez Git, donc les éviter est une grave erreur.

Marnen Laibow-Koser
la source
-1

Il existe d’excellentes solutions techniques telles que celle mentionnée par @jdunay, mais pour nous, c’est une question de personnel - de la même manière que créer un environnement dans lequel les personnes s’engagent est souvent une question de personnel.

Ce qui a fonctionné pour nous est: (remplacez 'master' par la branche dev actuellement active)

  1. Fusions fréquentes / rebases du maître
  2. Assez fréquentes pour maîtriser
  3. Prendre conscience des éléments qui provoquent la fusion de l’enfer, tels que certains refactorings, et atténuer cet inconvénient en communiquant. Par exemple:

    • Assurez-vous que tout le monde pousse avant le déjeuner
    • Effectuer et pousser le refactoring pendant le déjeuner
    • Assurez-vous que tout le monde tire après le déjeuner
orip
la source