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

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é?

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".

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.

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é.

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.

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.

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.

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.

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).

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é.

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).

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.

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