Utilisation de Mercurial dans une grande organisation

Question

J'utilise Mercurial pour mes projets personnels depuis un certain temps, et je l'adore. Mon employeur envisage de passer de CVS à SVN, mais je me demande si je ne devrais pas plutôt opter pour Mercurial (ou un autre DVCS).

Un problème avec Mercurial est qu'il semble être conçu autour de l'idée d'avoir un seul dépôt par "projet". Dans cette organisation, il y a des dizaines d'exécutables, de DLLs et d'autres composants différents dans le dépôt CVS actuel, organisés hiérarchiquement. Il y a beaucoup de composants génériques réutilisables, mais aussi des composants spécifiques au client, et des configurations spécifiques au client. Les procédures de construction actuelles extraient généralement un ensemble de sous-arbres du référentiel CVS.

Si nous passons de CVS à Mercurial, quelle est la meilleure façon d'organiser le/les référentiel(s) ? Devrions-nous avoir un énorme dépôt Mercurial contenant tout ? Sinon, quelle devrait être la finesse des petits dépôts ? Je pense que les gens seront très ennuyés s'ils doivent tirer et pousser des mises à jour à partir de nombreux endroits différents, mais ils seront également ennuyés s'ils doivent tirer/pousser l'ensemble du code de l'entreprise.

Quelqu'un a une expérience dans ce domaine, ou des conseils ?

---

Questions connexes :

• Le contrôle de source basé sur Git dans l'entreprise : Outils et pratiques suggérés ?
• Le contrôle de version distribué pour les projets de grande envergure - est-ce faisable ?

Answer 1

Divulgation : Ceci est un poste secondaire d'un autre fil de discussion qui était axé sur git, mais j'ai fini par recommander mercurial de toute façon. Il traite de DVCS dans un contexte d'entreprise en général, donc j'espère que la publication croisée est acceptable. Je l'ai un peu modifié pour mieux répondre à cette question :

---

Contrairement à l'opinion générale, je pense que l'utilisation d'un DVCS est un choix idéal dans un contexte d'entreprise car il permet des flux de travail très flexibles. Je parlerai d'abord de l'utilisation d'un DVCS par rapport à un CVCS, des meilleures pratiques, puis de git en particulier.

DVCS vs. CVCS dans un contexte d'entreprise :

Je ne parlerai pas ici des avantages et inconvénients généraux, mais je me concentrerai plutôt sur votre contexte. Il est communément admis que l'utilisation d'un DVCS requiert une équipe plus disciplinée que l'utilisation d'un système centralisé. Cela est dû au fait qu'un système centralisé vous offre un moyen facile de appliquer votre flux de travail, l'utilisation d'un système décentralisé requiert plus de communication et la discipline pour s'en tenir aux conventions établies. Bien que cela puisse sembler induire des frais généraux, je vois un avantage dans la communication accrue nécessaire pour en faire un bon processus. Votre équipe devra communiquer au sujet du code, des changements et de l'état du projet en général.

Une autre dimension dans le contexte de la discipline est d'encourager les ramifications et les expériences. Voici un extrait d'un récent article de Martin Fowler sur bliki sur les outils de contrôle de version il a trouvé une description très concise de ce phénomène.

Le DVCS encourage les embranchements rapides pour l'expérimentation. Vous pouvez faire des branches dans Subversion, mais le fait qu'ils sont visibles par tous décourage les gens d'ouvrir une branche pour travail expérimental. De même, un DVCS encourage les points de contrôle du travail : commettre des changements incomplets, qui qui ne compilent pas ou ne passent pas les tests. votre dépôt local. Encore une fois, vous pouvez faire cela sur une branche de développement dans Subversion, mais le fait que de telles branches sont dans l'espace partagé rend les gens sont moins enclins à le faire.

Les DVCS permettent des flux de travail flexibles parce qu'ils fournissent un suivi des jeux de modifications par le biais d'identifiants uniques au monde dans un graphe acyclique dirigé (DAG) au lieu de simples différences textuelles. Cela leur permet de suivre de manière transparente l'origine et l'historique d'un jeu de modifications, ce qui peut être très important.

Flux de travail :

Larry Osterman (un développeur de Microsoft travaillant dans l'équipe Windows) a une excellent article de blog sur le flux de travail qu'ils emploient dans l'équipe Windows. Plus particulièrement, ils ont :

• Un tronc de code propre et de haute qualité uniquement (master repo)
• Tout le développement se fait sur les branches de fonctionnalité
• Les équipes de fonctionnalité ont des dépôts d'équipe
• Ils fusionnent régulièrement les dernières modifications du tronc dans leur branche de fonctionnalité ( Forward Integrate )
• Les fonctionnalités complètes doivent passer plusieurs tests de qualité, par exemple la révision, la couverture des tests, les questions et réponses (dépôts autonomes).
• Si une fonctionnalité est terminée et que sa qualité est acceptable, elle est intégrée au tronc ( Inverser l'intégration )

Comme vous pouvez le constater, le fait que chacun de ces référentiels soit autonome permet de découpler les différentes équipes qui avancent à des rythmes différents. La possibilité de mettre en œuvre un système flexible de contrôle de la qualité distingue également le DVCS du CVCS. Vous pouvez également résoudre vos problèmes de permission à ce niveau. Seule une poignée de personnes devrait être autorisée à accéder au master repo. Pour chaque niveau de la hiérarchie, ayez un repo séparé avec les politiques d'accès correspondantes. En effet, cette approche peut être très flexible au niveau de l'équipe. Vous devriez laisser à chaque équipe le soin de décider si elle souhaite partager son repo d'équipe entre elles ou si elle souhaite une approche plus hiérarchique où seul le chef d'équipe peut s'engager dans le repo d'équipe.

(L'image est volée à l'ouvrage de Joel Spolsky intitulé hginit.com .)

Une chose reste à dire à ce stade, même si DVCS offre de grandes capacités de fusion, c'est jamais un remplacement de l'utilisation de l'intégration continue. Même à ce stade, vous disposez d'une grande flexibilité : CI pour le trunk repo, CI pour les repos d'équipe, les repos Q&A, etc.

Mercurial dans un contexte d'entreprise :

Je ne veux pas lancer une guerre de mots entre git et hg ici, vous êtes déjà sur la bonne voie en envisageant de passer à DVCS. Voici quelques raisons d'utiliser Mercurial au lieu de git :

• Toutes les plates-formes qui utilisent python sont supportées.
• Excellents outils d'interface graphique sur toutes les principales plates-formes (win/linux/OS X), intégration d'outils de fusion/diffusion de premier ordre.
• Interface très cohérente, transition facile pour les utilisateurs de svn
• Peut faire la plupart des choses que git peut faire aussi, mais fournit une abstraction plus propre. Les opérations dangereuses sont toujours explicites. Les fonctionnalités avancées sont fournies via des extensions qui doivent être explicitement activées.
• Un soutien commercial est disponible de selenic.

En bref, lorsque l'on utilise le DVCS dans une entreprise, je pense qu'il est important de choisir un outil qui introduit le moins de friction possible. Pour que la transition soit réussie, il est particulièrement important de tenir compte des compétences variables des développeurs (en ce qui concerne les VCS).

Il y a quelques ressources que j'aimerais vous indiquer à la fin. Joel Spolsky a récemment écrit un article battant en brèche beaucoup d'arguments avancés contre le DVCS. Il faut préciser que d'autres ont découvert ces contre-arguments bien avant. Une autre bonne ressource est le blog d'Eric Sinks, où il a écrit un article sur Obstacles à un DVCS d'entreprise .

Answer 2

La plupart des résistances aux DVCS sont dues au fait que les gens ne comprennent pas comment les utiliser. La déclaration souvent répétée selon laquelle "il n'y a pas de dépôt central" est très effrayante pour les personnes qui ont été enfermées dans le modèle CVS/SVN depuis des temps immémoriaux et qui ne peuvent pas imaginer autre chose, en particulier pour la direction et les développeurs seniors (expérimentés et/ou cyniques) qui veulent un suivi du code source et une reproductibilité solides (et peut-être aussi si vous devez satisfaire à certaines normes concernant vos processus de développement, comme c'était le cas à un endroit où j'ai travaillé une fois). Vous pouvez avoir un dépôt central "béni", mais vous n'y êtes pas contraint. Il est facile pour une sous-équipe de mettre en place un repo de terrain de jeu interne sur l'une de ses stations de travail pendant un certain temps, par exemple.

Il y a tellement de façons d'écorcher le chat que vous aurez intérêt à vous asseoir et à bien réfléchir à votre flux de travail. Réfléchissez à vos pratiques actuelles et à la puissance que vous offrent le clonage et le branchement quasi gratuits. Il est probable que certaines de vos pratiques actuelles aient évolué pour contourner les limites du modèle de type CVS ; soyez prêt à briser le moule. Vous aurez probablement besoin de nommer un ou deux champions pour faciliter la transition ; avec une grande équipe, vous voudrez probablement penser à restreindre l'accès aux commit aux personnes suivantes béni .

À mon travail (petite entreprise de logiciels), nous sommes passés de CVS à hg et nous n'avons pas voulu revenir en arrière. Nous l'utilisons de manière essentiellement centralisée. La conversion de notre principal dépôt (ancien et très volumineux) a été douloureuse, mais elle le sera quelle que soit la méthode choisie, et quand c'est fait, c'est fait - il sera beaucoup plus facile de changer de VCS plus tard. (Nous avons trouvé un certain nombre de situations où les outils de conversion CVS ne peuvent tout simplement pas comprendre ce qui s'est passé ; lorsque le commit de quelqu'un n'a réussi que partiellement et qu'il ne l'a pas remarqué pendant des jours ; la résolution des branches des vendeurs ; la folie générale et la démence causée par le temps qui semble reculer, ce qui n'est pas aidé par les timestamps de commit en temps local provenant de différents fuseaux horaires...)

Le grand avantage que j'ai trouvé à un DVCS est la possibilité de commettre tôt et souvent et de pousser seulement quand c'est prêt. Lorsque j'atteins les différentes étapes du travail en cours, j'aime poser une ligne dans le sable afin d'avoir un endroit où je peux revenir en arrière si nécessaire - mais ce ne sont pas des commits qui doivent être exposés à l'équipe car ils sont manifestement incomplets de multiples façons. (Je fais cela principalement avec les files d'attente mercuriales). Tout est dans le flux de travail ; je n'aurais jamais pu faire cela avec CVS.

Je suppose que vous le savez déjà, mais si vous envisagez de vous éloigner de CVS, vous pouvez faire tellement mieux que SVN...

---

Monolithique ou modulaire ? Tout changement de paradigme sera délicat quel que soit le VCS avec lequel vous travaillez, qu'il soit distribué ou non ; le modèle CVS est assez spécial dans la mesure où il vous permet de livrer sur une base fichier par fichier sans vérifier si le reste du repo est à jour (et ne parlons pas du mal de tête que les alias de modules sont connus pour causer).

• La gestion des référentiels monolithiques peut être assez lente. Votre client vcs doit scanner votre copie de l'univers entier pour les changements, par opposition à un seul module. (Si vous travaillez sous Linux, jetez un œil à l'extension hg inotify si vous ne l'avez pas déjà fait).
• Un repo monolithique provoque également des conditions de course inutiles lors du committing(pushing). C'est comme la vérification de la mise à jour de CVS, mais appliquée à l'ensemble du repo : si vous avez beaucoup de développeurs actifs, qui commettent fréquemment, cette situation vous pèsera.

Je dirais que cela vaut la peine de s'éloigner du monolithique, mais attention, cela imposera ses propres frais généraux en termes de complexité supplémentaire dans votre système de construction. (Note complémentaire : si vous trouvez que quelque chose est une corvée fastidieuse, automatisez-la ! Nous, les programmeurs, sommes des créatures paresseuses, après tout). La division de votre dépôt en tous les modules qui le composent peut être trop extrême ; il peut y avoir un compromis à trouver avec des composants apparentés regroupés dans un petit nombre de dépôts. Vous pouvez également trouver utile d'examiner le support des sous-modules de mercurial. Référentiels imbriqués y el Extension de la forêt (deux choses que je devrais essayer de comprendre).

Sur un ancien lieu de travail, nous avions plusieurs dizaines de composants qui étaient conservés en tant que modules CVS indépendants avec une métastructure assez régimentée. Les composants déclaraient ce dont ils dépendaient et quelles parties construites devaient être exportées à quel endroit ; le système de construction écrivait automatiquement les fragments make pour que ce sur quoi vous travailliez prenne ce dont il avait besoin. Cela fonctionnait généralement très bien et il était assez rare d'échouer à la vérification de la mise à jour du CVS. (Il y avait aussi un robot de compilation extrêmement compliqué mais extrêmement puissant, qui avait une attitude de moindre effort pour la résolution des dépendances : il ne reconstruisait pas un composant s'il y en avait déjà un qui répondait à vos besoins. Ajoutez à cela des méta-composants qui assemblaient des installateurs et des images ISO entières, et vous avez une bonne recette pour des constructions faciles de début à la fin et pour des choses qui vont de l'Apprenti sorcier. Quelqu'un devrait écrire un livre à ce sujet...)

Answer 3

Tout d'abord, une discussion récente sur l'utilisation d'un DVCS dans les grands projets est pertinente :

Le contrôle de version distribué pour les projets de grande envergure - est-ce faisable ?

Un problème avec Mercurial est qu'il semble être conçu autour de l'idée d'avoir un seul dépôt par "projet".

Oui, alors que la norme avec Subversion est d'avoir un dépôt monolithique contenant plusieurs projets, avec un DVCS il est préférable d'avoir des dépôts plus granulaires, avec un par composant. Subversion a le svn:externals pour agréger plusieurs arbres sources au moment de la vérification (ce qui pose ses propres problèmes logistiques et techniques). Mercurial et Git ont tous deux une fonctionnalité similaire, appelée subrepos en hg.

L'idée avec les sous-référentiels est que vous avez un référentiel par composant, et qu'un produit libérable (comprenant plusieurs composants réutilisables) fera simplement référence à ses référentiels dépendants. Lorsque vous clonez le repo du produit, il apporte les composants dont il a besoin.

Devrions-nous avoir un énorme dépôt Mercurial contenant tout ? Si ce n'est pas le cas, quelle devrait être la finesse des petits dépôts ? Je pense que les gens seront très ennuyés s'ils doivent tirer et pousser des mises à jour à partir de nombreux endroits différents, mais ils seront également ennuyés s'ils doivent tirer/pousser l'ensemble du code de l'entreprise.

Il est tout à fait possible d'avoir un référentiel monolithique (et vous pouvez même le diviser par la suite si vous en avez besoin). Les problèmes liés à cette approche sont plutôt liés aux calendriers de publication et à la façon dont vous gérez les différentes versions des différents composants. Si vous avez plusieurs produits avec leurs propres calendriers de publication partageant des composants communs, il serait probablement préférable d'adopter une approche plus granulaire, afin de faciliter la gestion de la configuration.

Une mise en garde s'impose : la prise en charge des sous-régies est une fonctionnalité relativement récente, qui n'est pas aussi aboutie que d'autres. Plus précisément, toutes les commandes hg ne connaissent pas les sous-références, bien que les plus importantes les connaissent.

Je vous suggère d'effectuer une conversion de test, et d'expérimenter avec le support de subrepo, l'organisation des produits et des composants dépendants, etc. Je suis en train de faire la même chose, et cela semble être la voie à suivre.