Systèmes de contrôle de version dissortingbués et l’entreprise – un bon mélange?

Je peux voir pourquoi les systèmes de contrôle des sources dissortingbuées (DVCS – comme Mercurial) ont un sens pour les projets open source.

Mais ont-ils un sens pour une entreprise? (sur un système de contrôle de source centralisé tel que TFS)

Quelles sont les caractéristiques d’un DVCS qui le rendent meilleur ou pire pour une entreprise avec de nombreux développeurs? (sur un système centralisé)

Je viens d’introduire un DVCS (Git dans ce cas) dans une grande entreprise bancaire, où Perforce, SVN ou ClearCase étaient les VCS centralisés des choix:
Je connaissais déjà les défis (voir ma réponse précédente ” Pouvons-nous finalement passer à DVCS dans les logiciels d’entreprise? SVN est-il toujours indispensable de développer? )

J’ai été défié sur trois fronts:

  • centralisation : alors que le modèle décentralisé a ses avantages (et permet des engagements privés ou fonctionne sans réseau tout en ayant access à l’historique complet ), il rest à définir clairement les mises en pension centralisées , qui constituent la principale référence pour tous les développeurs.

  • authentification : un DVCS vous permet de “signer” (valider) votre code comme … à peu près n’importe qui (auteur ” foo “, email ” foo@bar.com “).
    Vous pouvez faire un git config user.name foo , ou git config user.name whateverNameIFeelToHave , et avoir tous vos commits avec un nom bidon.
    Cela ne se marie pas bien avec l’unique référentiel utilisateur centralisé “Active Directory” utilisé par les grandes entresockets.

  • autorisation : par défaut, vous pouvez cloner, envoyer depuis ou vers n’importe quel référentiel et modifier une twig ou un répertoire.
    Pour les projets sensibles, cela peut constituer un problème de blocage (le monde bancaire est généralement très protecteur de certains algorithmes de prix ou de quants, qui exigent un access en lecture / écriture ssortingct pour un nombre très limité de personnes).

La réponse (pour une configuration Git) était la suivante:

  • centralisation : un serveur unique a été configuré pour que tout référentiel soit accessible par tous les utilisateurs.
    La sauvegarde a été effectuée (incrémentielle chaque jour, complète chaque semaine).
    Le DRP (Disaster Recovery Plan) a été implémenté avec un second serveur sur un autre site et une réplication des données en temps réel via SRDF .
    Cette configuration en elle-même est indépendante du type de référentiel ou d’outil dont vous avez besoin (DVCS, référentiel Nexus ou ordonnanceur principal Hudson, ou …): tout outil pouvant être critique pour une mise en production doit être installé sur des serveurs. avec sauvegarde et DR.

.

  • authentification : seuls deux protocoles permettent aux utilisateurs d’accéder aux repos principaux:
    • ssh, avec clé publique / privée:
      • utile pour les utilisateurs externes à l’organisation (comme le développement offshore),
      • et utile pour les comptes génériques que le gestionnaire Active Directory ne veut pas créer (car ce serait un compte “anonyme”): une personne réelle doit être responsable de ce compte générique, et ce serait celle qui possède la clé privée.
    • Basé sur https, avec un serveur Apache qui authentifie les utilisateurs via un paramètre LDAP: un identifiant réel doit être fourni pour toute opération git sur ces repos.
      Git le propose avec son protocole http intelligent , permettant non seulement de pull (lire) via http, mais aussi de push (écrire) via http.

La partie authentification est également renforcée au niveau Git par un hook post-receive qui vérifie qu’au moins un des commits que vous poussez à un référentiel a un “nom de committer” égal au nom d’utilisateur détecté via le protocole shh ou http.
En d’autres termes, vous devez configurer votre git config user.name correctement, ou toute poussée que vous souhaitez effectuer sur un repository central sera rejetée.

.

  • autorisation : les deux parameters précédents (ssh ou https) sont câblés pour appeler le même ensemble de script perl, nommé gitolite , avec comme parameters:
    • le nom d’utilisateur réel détecté par ces deux protocoles
    • la commande git (clone, push ou pull) que l’utilisateur veut faire

Le script gitolite perl parsingra un simple fichier texte où les permissions (access en lecture / écriture pour un référentiel entier, ou pour des twigs dans un référentiel donné, ou même pour des répertoires dans un référentiel) ont été définies.
Si le niveau d’access requirejs par la commande git ne correspond pas à la liste de contrôle d’access définie dans ce fichier, la commande est rejetée.


Ce qui précède décrit ce que je devais mettre en œuvre pour un paramètre Git, mais plus important encore, il répertorie les principaux problèmes à résoudre pour qu’un paramètre DVCS ait du sens dans une grande entreprise avec une base d’utilisateurs unique.

Alors, et alors seulement, un DVCS (Git, Mercurial, …) peut append des valeurs à cause de:

  • échange de données entre plusieurs sites : alors que ces utilisateurs sont tous authentifiés via le même Active Directory, ils peuvent être répartis dans le monde entier (les sociétés pour lesquelles j’ai travaillé ont des développements généralement entre deux ou trois pays). Un DVCS est naturellement conçu pour échanger efficacement des données entre ces équipes dissortingbuées.

  • réplication à travers les environnements : un paramètre prenant en charge l’authentification / autorisation permet de cloner ces référentiels sur d’autres serveurs dédiés (pour les tests d’intégration, les tests UAT, la pré-production et le pré-déploiement)

  • automatisation des processus : la facilité avec laquelle vous pouvez cloner un repo peut également être utilisée localement sur le poste de travail d’un utilisateur, à des fins de test unitaire avec les techniques de “commits gardés” et autres utilisations intelligentes: voir vous avez déjà vu? “.
    En bref, vous pouvez faire appel à un deuxième repo local chargé de:

    • diverses tâches (test unitaire ou parsing statique du code)
    • repoussant au repo principal si ces tâches sont réussies
    • pendant que vous travaillez encore dans le premier repo sans avoir à attendre le résultat de ces tâches.

.

  • fonctions killer : Tout DVCS vient avec ceux, le principal étant la fusion (jamais essayé de faire un stream de travail de fusion complexe avec SVN? Ou fusionner lentement 6000 fichiers avec ClearCase?).
    Cela seul (la fusion) signifie que vous pouvez vraiment tirer parti des twigments , tout en pouvant à tout moment fusionner votre code avec une autre ligne de développement principale, car vous le feriez:
    • d’abord localement dans votre propre repo, sans déranger personne
    • puis sur le serveur distant, en poussant le résultat de cette fusion sur le repo central.

Pour append aux autres commentaires, je constate qu’il n’y a aucune raison pour laquelle vous ne pouvez pas avoir un référentiel central d’entreprise . Techniquement, c’est juste un autre repository, mais c’est celui à partir duquel vous envoyez la production. J’utilise une forme ou une autre de VCS depuis plus de 30 ans et je peux dire que passer à Mercurial était comme un garçon de la ville qui respirait l’air pur du pays pour la première fois.

Les DSCS ont une meilleure histoire (généralement) que les systèmes centralisés pour les réseaux hors ligne ou lents. Ils ont tendance à être plus rapides, ce qui est vraiment perceptible pour les développeurs (utilisant TDD) qui effectuent de nombreux check-ins.

Les systèmes centralisés sont un peu plus faciles à comprendre au départ et pourraient constituer un meilleur choix pour les développeurs moins expérimentés. Les DVCS vous permettent de créer de nombreuses mini-twigs et d’isoler les nouvelles fonctionnalités tout en effectuant une vérification de red-gree-refactor sur le style de codage en vert. Encore une fois, cela est très puissant, mais seulement attrayant pour les équipes de développement assez avertis.

Avoir un référentiel central unique pour la prise en charge des verrous exclusifs prend tout son sens si vous traitez des fichiers qui ne peuvent pas être fusionnés comme les fichiers numériques et les documents non textuels (PDF, Word, etc.).

Je ne pense pas que le nombre de développeurs ou la taille de la base de code y jouent un rôle important, les deux systèmes ont été conçus pour prendre en charge de grandes arborescences de sources et le nombre de committers. Toutefois, pour les bases de code et les projets volumineux, le DVCS offre une grande souplesse dans la création rapide de succursales décentralisées. Vous pouvez le faire avec des systèmes centralisés, mais vous devez être plus délibéré à ce sujet, ce qui est à la fois bon et mauvais.

En bref, certains aspects techniques doivent être pris en compte, mais vous devez également penser à la maturité de votre équipe et à son processus actuel en matière de SCCS.

Au moins avec tfs 2013, vous avez la possibilité de travailler déconnecté avec les espaces de travail locaux. Le secteur dissortingbué vs centralisé est défini par l’entreprise et dépend des besoins et des exigences des projets en développement.

Pour les projets d’entreprise, la possibilité de connecter des stream de travail et des documents à des modifications de code peut être essentielle pour relier les exigences métier et les éléments d’ordre supérieur à des modifications de code spécifiques portant sur une modification, un bogue ou une fonctionnalité spécifique.

Cette connexion entre le workflow et le référentiel de code sépare les solutions TFS de référentiel de code uniquement. Pour certains endroits où un audit de projet plus poussé est requirejs, seul un produit tel que TFS satisferait davantage aux exigences de l’audit du projet.

Vous trouverez ici un aperçu du processus de gestion du cycle de vie des applications.

http://msdn.microsoft.com/en-us/library/vstudio/fda2bad5(v=vs.110).aspx

Le plus gros problème auquel nous sums confrontés avec Git dans le cadre de l’entreprise est le manque de contrôle d’access en lecture basé sur les chemins. Il est inhérent à l’architecture de Git (et je suppose que la plupart des DVCS) que si vous avez un access en lecture au référentiel, vous obtenez tout. Mais parfois, un projet nécessiterait une extraction clairsemée (c.-à-d. Que vous voulez contrôler la version des données sensibles près de la source, ou vous voulez donner à une tierce partie une vue sélective d’une partie du projet).

Out of the box, Git ne fournit aucune autorisation – vous avez des hooks pour écrire les vôtres.

La plupart des gestionnaires de pensions populaires GithubEnterprise, Gitlab, Bitbucket fournissent des ressortingctions d’écriture basées sur les twigs. Gitolite permet d’être à grain plus fin, fournissant des ressortingctions d’écriture basées sur le chemin (et plus).

Le seul gestionnaire de repo que j’ai entendu parler de la prise en charge de l’access en lecture est l’Helix Perforce, qui réimplémente le protocole git par-dessus le backend perforce, mais je n’ai aucune expérience pratique avec ce dernier. C’est prometteur, mais je serais inquiet à quel point il est compatible avec “plain” git.

Pour moi, la plus grande chose qu’ils proposent est la vitesse. Ils sont des ordres de grandeur plus rapides pour les opérations les plus courantes que le contrôle centralisé des sources.

Travailler déconnecté est également un énorme avantage.

Absolument, un modèle de source dissortingbuée peut avoir du sens dans une entreprise, mais cela dépend de la structure de vos équipes.

Le contrôle de source dissortingbué vous offre la possibilité de créer vos propres stream de travail.

Imaginez, si vous voulez, une équipe plus importante au sein de laquelle des équipes plus petites travaillent sur des twigs distinctes.

  • Ces équipes peuvent toutes avoir leurs propres référentiels centraux, avec leurs propres mécanismes de contrôle d’automatisation / vérification.
  • Ils peuvent travailler n’importe où et sauvegarder leur travail local quand ils le souhaitent.
  • Ils peuvent ensuite choisir les checkins qu’ils souhaitent partager entre les groupes.
  • Ils peuvent avoir un seul intégrateur individuel, travaillant sur leur propre machine, effectuant la fusion sans impact sur les autres.

Ce sont des choses que vous pouvez réaliser avec un serveur centralisé traditionnel, mais comme le souligne @Brook, le modèle centralisé doit évoluer, alors que le modèle dissortingbué est déjà fragmenté, donc aucun (ou du moins) moins

Notre équipe a utilisé TFS pendant environ 3 ans avant de passer à Mercurial. Le support de twig / fusion de HG est tellement meilleur que TFS. Cela est dû au fait que le DVCS repose sur une fusion sans douleur.

Meilleure synchronisation entre les sites distants / déconnectés.