Le contrôle de source basé sur Git dans l'entreprise : Outils et pratiques suggérés ?

Question

J'utilise git pour mes projets personnels et je pense que c'est génial. Il est rapide, flexible, puissant et fonctionne très bien pour le développement à distance.

Mais maintenant, c'est obligatoire au travail et, franchement, nous avons des problèmes.

En l'état, git ne semble pas bien fonctionner pour le développement centralisé dans une grande organisation (plus de 20 développeurs) avec des développeurs aux capacités et aux niveaux de sophistication de git variables - surtout en comparaison avec d'autres systèmes de contrôle de source comme Perforce ou Subversion, qui sont destinés à ce type d'environnement. (Oui, je sais, Linus ne l'a jamais destiné à cela).

Mais - pour des raisons politiques - nous sommes coincés avec git, même si c'est nul pour ce que nous essayons de faire avec.

Voici quelques-unes des choses que nous voyons :

• Les outils GUI ne sont pas matures
• En utilisant les outils en ligne de commande, il est beaucoup trop facile de faire échouer une fusion et d'effacer les modifications apportées par quelqu'un d'autre.
• Il n'offre pas de permissions de dépôt par utilisateur au-delà des privilèges globaux de lecture seule ou de lecture-écriture.
• Si vous avez une permission pour N'IMPORTE QUELLE partie d'un dépôt, vous pouvez faire la même chose pour TOUTES les parties du dépôt, donc vous ne pouvez pas faire quelque chose comme créer une branche de suivi de petit groupe sur le serveur central que les autres personnes ne peuvent pas toucher.
• Il est difficile d'encourager, et encore moins de faire respecter, les flux de travail autres que le "tout est permis" ou le "dictateur bienveillant".
• Il n'est pas évident de savoir s'il est préférable d'utiliser un seul grand dépôt (qui permet à tout le monde de toucher à tout) ou un grand nombre de dépôts par composant (qui donnent lieu à des maux de tête lors de la synchronisation des versions).
• Avec de multiples dépôts, il n'est pas non plus évident de reproduire toutes les sources que quelqu'un d'autre possède en puisant dans le dépôt central, ou de faire quelque chose comme obtenir tout ce qui se trouve à 16h30 hier après-midi.

Cependant, j'ai entendu dire que des gens utilisent git avec succès dans de grandes organisations de développement.

Si vous vous trouvez dans cette situation - ou si vous disposez d'outils, de conseils et d'astuces pour faciliter et rendre plus productive l'utilisation de git dans une grande organisation où certaines personnes ne sont pas des adeptes de la ligne de commande - j'aimerais entendre ce que vous avez à suggérer.

D'ailleurs, j'ai déjà posé une version de cette question sur LinkedIn, et je n'ai obtenu aucune véritable réponse, mais beaucoup de "bon sang, j'aimerais bien le savoir aussi !".

UPDATE : Laissez-moi clarifier...

Là où je travaille, nous ne pouvons pas utiliser autre chose que git. . Ce n'est pas une option. Nous sommes coincés avec ça. Nous ne pouvons pas utiliser mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS, ou même le bon vieux Projector d'Apple que j'utilisais en 1987. Donc, même si vous êtes les bienvenus pour discuter d'autres options, Tu n'auras pas la prime si tu ne discutes pas avec Git.

Aussi, je suis à la recherche de conseils pratiques sur l'utilisation de git dans l'entreprise . J'ai mis toute une liste de problèmes que nous rencontrons en haut de cette question. Encore une fois, les gens sont les bienvenus pour discuter de la théorie, mais si vous voulez gagner la prime, donnez-moi des solutions.

Answer 1

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 fournit un moyen facile de appliquer votre flux de travail, l'utilisation d'un système décentralisé nécessite 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 de l'entrée récente 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 effectuer des branchements dans Subversion, mais le fait qu'elles 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 car ils fournissent un suivi des jeux de modifications par le biais d'identifiants uniques 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 place 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 dépôt maître. 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 cependant à dire à ce stade : même si le DVCS offre d'excellentes 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.

Git dans un contexte d'entreprise :

Git n'est peut-être pas la solution idéale pour un contexte d'entreprise comme vous l'avez déjà souligné. Pour reprendre certaines de vos préoccupations, je pense que les plus importantes sont les suivantes :

• Support encore quelque peu immature sur Windows (veuillez me corriger si cela a changé récemment) Maintenant, Windows a client Windows de github , tortoisegit , SourceTree de atlassian
• Manque d'outils GUI matures, pas d'intégration d'outils vdiff/merge de première classe
• Interface incohérente avec un très faible niveau d'abstractions au-dessus de son fonctionnement interne.
• Une courbe d'apprentissage très raide pour les utilisateurs de svn
• Git est très puissant et permet facile pour modifier l'histoire, très dangereux si vous ne savez pas ce que vous faites (et vous le ferez parfois même si vous pensiez le savoir)
• Aucune option d'assistance commerciale disponible

Je ne veux pas commencer une guerre de mots entre git et hg ici, vous avez déjà fait le bon choix en passant à un DVCS. Mercurial répond à certains des points ci-dessus et je pense qu'il est donc mieux adapté dans un contexte d'entreprise :

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

---

Réduire la friction :

Ok, puisque vous semblez être vraiment coincé avec la situation, il reste deux options IMHO. Il n'existe pas d'outil pour rendre git moins compliqué ; git es compliqué. Soit vous affrontez cela, soit vous travaillez autour de git :-

1. Obtenir un cours d'introduction à git pour toute l'équipe. Cela devrait inclure uniquement les bases et quelques exercices (important !).
2. Convertir le dépôt maître en svn et laisser les " jeunes étoiles ". git-svn . Cela donne à la plupart des développeurs une interface facile à utiliser et peut compenser le manque de discipline dans votre équipe, tandis que les jeunes étoiles peuvent continuer à utiliser git pour leurs propres dépôts.

Pour être honnête, je pense que vous avez vraiment un problème de personnes plutôt qu'un problème d'outils. Que peut-on faire pour améliorer cette situation ?

• Vous devez indiquer clairement que vous pensez que votre processus actuel aboutira à une base de code maintenable.
• Investissez du temps dans l'intégration continue. Comme je l'ai souligné ci-dessus, quel que soit le type de VCS que vous utilisez, il n'y a jamais de remplacement pour l'IC. Vous avez déclaré qu'il y a des gens qui poussent de la merde dans le master repo : Faites-leur corriger leurs conneries pendant qu'une alerte rouge se déclenche et leur reproche d'avoir cassé la construction (ou de ne pas respecter une mesure de qualité ou autre).

Answer 2

Je suis l'ingénieur SCM d'une organisation de développement assez importante, et nous sommes passés de svn à git au cours de l'année dernière. Nous l'utilisons de manière centralisée.

Nous utilisons gitosis pour héberger les référentiels. Nous avons divisé nos dépôts svn monolithiques en de nombreux dépôts git plus petits, car l'unité de branchement de git est fondamentalement le dépôt. (Il existe des moyens de contourner cela, mais ils sont maladroits.) Si vous voulez des contrôles d'accès par branche, gitolite pourrait être une meilleure approche. Il y a aussi une version de l'intérieur du pare-feu de GitHub si vous voulez dépenser de l'argent. Pour nos besoins, gitosis est parfait parce que nous avons des permissions assez ouvertes sur nos dépôts. (Nous avons des groupes de personnes qui ont un accès en écriture à des groupes de dépôts, et tout le monde a un accès en lecture à tous les dépôts). Nous utilisons gitweb pour une interface web.

Quant à certaines de vos préoccupations spécifiques :

• fusionne : Vous pouvez utiliser un outil de fusion visuel de votre choix ; il existe des instructions à divers endroits sur la façon de le configurer. Le fait que vous puissiez effectuer la fusion et vérifier sa validité entièrement sur votre dépôt local est, à mon avis, un atout majeur de git ; vous pouvez vérifier la fusion avant de pousser quoi que ce soit.
• GUIs : Nous avons quelques personnes qui utilisent TortoiseGit mais je ne le recommande pas vraiment ; il semble interagir de façon étrange avec la ligne de commande. Je dois admettre que c'est un domaine qui doit être amélioré. (Cela dit, je ne suis pas un fan des interfaces graphiques pour le contrôle de version en général).
• branches de suivi en petits groupes : Si vous utilisez quelque chose qui fournit des ACL à grain fin comme gitolite, il est assez facile de le faire, mais vous pouvez également créer une branche partagée en connectant les dépôts locaux de divers développeurs - un dépôt git peut avoir plusieurs remotes.

Nous sommes passés à git parce que nous avons beaucoup de développeurs à distance, et parce que nous avions de nombreux problèmes avec Subversion. Nous sommes encore en train d'expérimenter les flux de travail, mais pour l'instant, nous l'utilisons essentiellement de la même manière que Subversion. Une autre chose que nous avons appréciée, c'est qu'elle a ouvert d'autres flux de travail possibles, comme l'utilisation de dépôts de stockage pour la révision du code et le partage du code entre petits groupes. Il a également encouragé beaucoup de gens à commencer à suivre leurs scripts personnels et ainsi de suite parce qu'il est si facile de créer un dépôt.

Answer 3

Oui, je sais, Linus ne l'a jamais prévu pour ça.

En fait, Linus soutient que les systèmes centralisés ne peuvent tout simplement pas fonctionner.

Et, quel est le problème avec le le flux de travail des dictateurs et des lieutenants ?

Rappelez-vous, git est un distribué n'essayez pas de l'utiliser comme un système central.

(mis à jour)

La plupart de vos problèmes disparaîtront si vous n'essayez pas d'utiliser git comme s'il s'agissait de "svn sous stéroïdes" (car ce n'est pas le cas).

Au lieu d'utiliser un dépôt nu comme serveur central vers lequel tout le monde peut pousser (et potentiellement faire des erreurs), configurez quelques gestionnaires d'intégration qui gèrent les fusions, afin qu'ils soient les seuls à pouvoir pousser vers le dépôt nu.

En général, ces personnes devraient être les chefs d'équipe : chaque chef intègre le travail de sa propre équipe et le pousse vers le référentiel béni.

Mieux encore, quelqu'un d'autre (c'est-à-dire le dictateur) s'inspire des chefs d'équipe et intègre leurs modifications dans le référentiel béni.

Il n'y a rien de mal à ce flux de travail, mais nous sommes une startup surchargée de travail et nous avons besoin de nos outils pour remplacer le temps et l'attention des humains ; personne n'a de bande passante pour faire des révisions de code, et encore moins pour être un dictateur bienveillant.

Si les intégrateurs n'ont pas le temps de réviser le code, c'est bien, mais il faut quand même avoir des gens qui intègrent les fusions de tout le monde.

Faire des pulls git ne prend pas tant de temps que ça.

git pull A
git pull B
git pull C

git fait un substitut au temps et à l'attention de l'homme ; c'est pourquoi il a été écrit en premier lieu.

• Les outils GUI ne sont pas matures

Les outils gui peuvent gérer les choses de base assez bien.

Les opérations avancées requièrent un esprit de codeur ou de bricoleur (par exemple, je suis à l'aise pour travailler à partir de la ligne de commande). Il faut un peu de temps pour comprendre les concepts, mais ce n'est pas si difficile.

• En utilisant les outils en ligne de commande, il est beaucoup trop facile de faire échouer une fusion et d'effacer les modifications apportées par quelqu'un d'autre.

Ce n'est pas un problème, sauf si vous avez de nombreux développeurs incompétents qui ont un accès total en écriture au "dépôt central".

Mais, si vous configurez votre flux de travail de manière à ce que seules quelques personnes (intégrateurs) écrivent dans le référentiel "béni", ce ne sera pas un problème.

Git ne rend pas facile le fait de foirer les fusions.

Lorsqu'il y a des conflits de fusion, git marque clairement les lignes en conflit afin que vous sachiez quelles modifications sont les vôtres et celles qui ne le sont pas.

Il est également facile d'oblitérer le code d'autrui avec svn ou tout autre outil (non distribué). En fait, c'est beaucoup plus facile avec ces autres outils parce que vous avez tendance à "vous asseoir sur les changements" pendant longtemps et à un certain point les fusions peuvent devenir horriblement difficiles.

Et comme ces outils ne savent pas comment fusionner, vous finissez toujours par devoir fusionner les choses manuellement. Par exemple, dès que quelqu'un fait un commit sur un fichier que vous éditez localement, il est marqué comme un conflit qui doit être résolu manuellement. que est un cauchemar de maintenance.

Avec git, la plupart du temps, il n'y aura pas de conflits de fusion car git peut réellement fusionner. Dans le cas où un conflit se produit, git marquera clairement les lignes pour vous afin que vous sachiez que exactement quels changements sont les vôtres et quels changements proviennent d'autres personnes.

Si quelqu'un efface les modifications d'autres personnes tout en résolvant un conflit de fusion, ce ne sera pas par erreur : ce sera soit parce que c'était nécessaire pour la résolution du conflit, soit parce qu'il ne sait pas ce qu'il fait.

• Il n'offre pas de permissions de dépôt par utilisateur au-delà des privilèges globaux de lecture seule ou de lecture-écriture.

• Si vous avez une permission pour N'IMPORTE QUELLE partie d'un dépôt, vous pouvez faire la même chose pour TOUTES les parties du dépôt, donc vous ne pouvez pas faire quelque chose comme créer une branche de suivi de petit groupe sur le serveur central que les autres personnes ne peuvent pas toucher.

• Il est difficile d'encourager, et encore moins de faire respecter, les flux de travail autres que le "tout est permis" ou le "dictateur bienveillant".

Ces problèmes disparaîtront lorsque vous cesserez d'essayer d'utiliser git comme s'il s'agissait d'un système centralisé.

• Il n'est pas évident de savoir s'il est préférable d'utiliser un seul grand dépôt (qui permet à tout le monde de toucher à tout) ou un grand nombre de dépôts par composant (qui donnent lieu à des maux de tête lors de la synchronisation des versions).

C'est un jugement.

Quel genre de projets avez-vous ?

Par exemple : la version x.y du projet A dépend-elle exactement de la version w.z du projet B de telle sorte que à chaque fois Si vous vérifiez x.y du projet A, vous devez également vérifier w.z du projet B, sinon il ne sera pas construit ? Si c'est le cas, je mettrais le projet A et le projet B dans le même référentiel, puisqu'ils sont manifestement deux parties d'un seul projet.

La meilleure pratique ici est de utilisez votre cerveau

• Avec de multiples dépôts, il n'est pas non plus évident de reproduire toutes les sources que quelqu'un d'autre possède en puisant dans le dépôt central, ou de faire quelque chose comme obtenir tout ce qui se trouve à 16h30 hier après-midi.

Je ne suis pas sûr de ce que vous voulez dire.

Answer 4

Je recommande vivement http://code.google.com/p/gerrit/ pour le travail en entreprise. Il vous offre un contrôle d'accès et un flux de travail intégré basé sur la révision. Il s'authentifie par rapport à n'importe quel système LDAP. Vous pouvez le connecter à Hudson avec http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin qui vous permet de construire et de tester des modifications alors qu'elles sont encore en cours d'examen ; c'est une configuration vraiment impressionnante.

Si vous décidez d'utiliser gerrit, je vous recommande d'essayer de garder un historique assez linéaire, et non un historique ramifié comme certains des gars de l'open source aiment. Gerrit formule cela de la manière suivante : " autoriser uniquement les changements en avance rapide ". Ensuite, vous pouvez utiliser le branching et le merging de la manière dont vous êtes habitué, pour les releases et autres.

Answer 5

Je réponds à cette question sur la base de mon expérience en tant que responsable du développement dans une grande entreprise de télécommunications, où nous avons adopté Git en 2010.

Vous avez des problèmes bien différents ici :

• flux de travail
• outils clients
• contrôle d'accès et intégration des serveurs

Flux de travail

Nous avons adopté avec succès un mode de dépôt central : ce que nous avons dans notre projet d'entreprise (un grand portail pour une base de 5 millions d'utilisateurs) est un dépôt central de facto qui produit les builds officiels qui sont ensuite pris à travers le processus de livraison (qui, dans notre cas, est composé de trois niveaux de tests et deux déploiements). Chaque développeur gère son propre dépôt, et nous travaillons sur la base d'une branche par fonctionnalité.

Outils pour les clients

Il y a maintenant plusieurs options disponibles, c'est maintenant un domaine très encombré. De nombreux développeurs utilisent avec succès Idée IntelliJ y Eclipse avec le plugin Git sans aucun autre élément. La plupart des développeurs Linux utilisent également le client CLI git, sans aucun problème. Certains développeurs Mac utilisent avec succès Tour Git . Veuillez noter que aucun de ces clients peut empêcher l'utilisateur de "mettre le bazar" dans le dépôt central : un mécanisme de contrôle côté serveur est nécessaire.

Contrôle d'accès et intégration des serveurs

Si vous voulez éviter que les développeurs ne "chamboulent" votre dépôt Git, vous devez absolument choisir une solution qui.. :

• expose une interface d'administration web décente pour effectuer chaque opération
• vous permet de faire respecter les identités des utilisateurs (en utilisant un dépôt Git "nu", il est extrêmement facile de commettre au nom de quelqu'un d'autre)
• vous fournit une sécurité fine (de sorte que, par exemple, vous pouvez empêcher le FORCE-PUSH et définir certaines branches en lecture seule pour certains développeurs / groupes)
• s'intégrer au système d'authentification de votre entreprise (par exemple, LDAP, Windows ActiveDirectory)
• vous fournit un audit complet (la conformité SOX est parfois très important pour les grandes entreprises)

Il n'y a pas beaucoup de solutions côté serveur prêtes à l'emploi qui peuvent aider à cela, je vous suggère de vérifier l'une d'entre elles :

• Gitorious Il peut fournir une sécurité de base au niveau de l'accès, mais il n'offre pas de contrôle fin des permissions. Vous devrez donc probablement coder pour gérer des scénarios tels que les permissions au niveau des branches. Il manque également d'intégration avec les mécanismes d'authentification d'entreprise existants.
• GitHub Enterprise : récemment publié par GitHub, il présente GitHub dans votre entreprise. Il manque la conformité SOX et la sécurité fine.
• Gerrit Il peut fournir une sécurité fine au niveau de l'accès et une intégration avec les systèmes d'authentification de l'entreprise, mais il n'est pas conforme à la loi SOX ni au SSO. De plus, certaines opérations ne peuvent être effectuées que par SSH via CLI.
• GitEnterprise Il fournit des autorisations au niveau des branches, un SSO, une conformité SOX et une administration entièrement basée sur le Web. Il a récemment été intégré à Gerrit, de sorte qu'il vous fournit également une instance Gerrit complète.

J'espère que cela vous aidera !