DVCS a béni la réplication du référentiel parmi les équipes réparties géographiquement

Mon entreprise explore le passage de Perforce à un DVCS et nous utilisons actuellement de nombreux proxys Perforce car les équipes de développement logiciel sont réparties sur l'Allemagne, la Chine, les États-Unis et le Mexique et parfois la bande passante d'un endroit à un autre n'est pas terrible.

En discutant avec l'informatique, nous avons commencé à chercher un moyen de maintenir le bon fonctionnement du point de vue géographiquement distribué afin que tout le monde obtienne le plus récent et le meilleur sans déterminer quel serveur de dépôt est la source de la vérité (c'est-à-dire la réplication transparente ).

Je pensais que nous pourrions peut - être émuler le mécanisme DNS via des crochets de pré-poussée et de pré-traction . Par exemple, considérons les pays A, B et C. En tirant de A béni, A lui-même tirera pour les changements de B, qui à son tour tirera pour les changements de C. Si B et C ont de nouveaux changements, ils tomberont vers A. Inversement, quand il y a une poussée, elle peut être propagée à tous les dépôts bénis.

Je suis conscient que, en général, vous n'avez qu'un seul dépôt béni, mais cela peut ne pas s'étendre à l'échelle mondiale et chaque dépôt béni serait juste applicable aux équipes d'un seul pays.

Ma question est : la conception de la réplication DVCS repo est-elle utilisée dans la pratique ?, quelqu'un l'a-t-il fait avec succès ?, si oui, quelle est la bonne façon de le faire?

Cette question concerne la réplication transparente , et je soupçonne qu'il n'y a pas encore de réponses parce que les gens pourraient être accrochés à la transparence. Je vais me permettre de mettre de côté la transparence pour le moment pour me concentrer sur la réplication. Je traiterai de la transparence (ou de la finesse) plus tard, et en fait, je ne pense pas que ce soit si important dans un DVCS.

Tout d'abord, permettez-moi de passer en revue quelques points clés sur le fonctionnement des référentiels dans un DVCS. (Je connais très bien Mercurial, c'est donc ce que je vais utiliser pour des exemples, mais je crois que tout ce que je dis est également vrai de git.)

A. Dans un DVCS, tout clone contient le même contenu de fichier et l'historique que l'original.

À condition de garder les dépôts correctement synchronisés, cela signifie que vous pouvez utiliser des opérations de propagation de changement DVCS ordinaires (cloner, pousser, tirer) et des dépôts ordinaires pour créer un système de réplication.

B. Les nouveaux changements ne doivent pas être propagés à leur origine.

En particulier, si je devais obtenir des modifications à partir d'un référentiel particulier et en ajouter quelques-unes, mes modifications n'auraient pas à revenir à ce référentiel particulier. Ils peuvent aller ailleurs. L'utilité de ceci devrait devenir claire à partir des exemples que je montrerai ci-dessous.

C. Les modifications peuvent être propagées par push ou pull.

Dans un système centralisé, de nouveaux changements peuvent à peu près (je pense) être introduits dans le repo. Dans un DVCS, il est possible de configurer une variété de topologies de propagation de changement, dont certaines impliquent uniquement l'extraction. Cela offre plus de flexibilité dans la configuration.

Exemples

Pour les besoins de la discussion, disons que vos équipes distribuées utilisent des systèmes dans les domaines duke.de, duke.us, duke.cn et duke.mx, et en outre que duke.de est l'endroit où nous voulons avoir le dépôt "béni". Compte tenu de ces hypothèses, permettez-moi de présenter un certain nombre d'exemples de différentes topologies que vous pourriez configurer, en gardant à l'esprit les trois points DVCS clés ci-dessus.

0. Modèle de poussée centralisée

Ayez un seul dépôt sur hg.duke.de et demandez aux développeurs de tous les emplacements de cloner et de tirer d'ici et de pousser les modifications ici. Cela pourrait fonctionner pour les gens en Allemagne, mais ce serait probablement un problème pour les gens du reste du monde. Toutes les opérations de clonage, d'extraction et de poussée passeraient par des liaisons réseau lentes à longue distance. Cela utilise un DVCS comme un système centralisé. C'est le problème que vous essayez de résoudre.

1. Push centralisé avec réplication

Ayez le dépôt béni sur hg.duke.de et des répliques sur hg.duke.cn, hg.duke.mx et hg.duke.us. Les développeurs clonent à partir de leur réplique locale et poussent les modifications vers hg.duke.de. Chaque fois que de nouvelles modifications apparaissent dans hg.duke.de, un hook s'exécute qui les propage aux répliques. Les répliques sont par ailleurs en lecture seule, il n'y aura donc jamais de fusion ou de conflit.

Si je suis un développeur au Mexique, par exemple, je clonerai à partir de hg.duke.mx mais je pousserai les modifications vers hg.duke.de. Si d'autres modifications sont poussées dans hg.duke.de avant que je puisse pousser mes modifications, ma poussée sera bloquée. Les autres modifications seront répliquées dans hg.duke.mx, je vais donc extraire ces modifications localement, fusionner, puis tenter de pousser à nouveau vers hg.duke.de.

Cela devrait fournir certains avantages, car les opérations de gros clone sont toutes effectuées localement. Pousser vers le référentiel central dans un autre emplacement n'est peut-être pas trop mauvais, car les changements sont poussés relativement rarement, les changements incrémentiels sont généralement assez faibles. (Mercurial en particulier envoie essentiellement des différences compressées, pas des fichiers entiers et leurs historiques.)

Dans Mercurial, vous pouvez configurer un dépôt local pour extraire d'un emplacement et pousser vers un autre en mettant quelque chose comme ce qui suit dans le .hg/hgrcfichier:

[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de

2. Modèle de traction simple

En continuant avec hg.duke.de en tant que dépôt béni et les autres en tant que répliques, nous pouvons propager les modifications via pull au lieu de push. Les développeurs clonent et tirent de leur réplique locale comme d'habitude. Lorsqu'une modification est prête, un développeur soumet une demande d'extraction à un service central, qui extrait du référentiel du développeur dans hg.duke.de. Une politique devra être établie pour les fusions. Par exemple, s'il existe des conflits de fusion, la demande peut être rejetée, obligeant le développeur à extraire (de la réplique locale), à ​​fusionner et à soumettre à nouveau la demande d'extraction.

Cette approche présente l'avantage de ne pas faire attendre le développeur pendant la propagation des modifications. Bien sûr, le développeur doit toujours attendre que la demande de tirage soit exécutée, mais au moins il peut travailler sur des modifications supplémentaires pendant ce temps.

Variations

Il existe un tas de variations qui peuvent être appliquées.

La soumission d'une demande d'extraction est un moment idéal pour l'examen du code. Les modifications sont publiées, en ce sens qu'elles sont accessibles à tous, mais elles n'ont pas encore été intégrées dans le dépôt béni.

Les demandes d'extraction peuvent être traitées manuellement ou par un système automatisé. Le traitement d'une demande d'extraction peut ne pas fusionner les modifications directement dans le référentiel béni, mais plutôt dans une zone de transit temporaire où un cycle de génération et de test est effectué. Ce n'est qu'après avoir réussi tous les tests que le jeu de modifications sera intégré au dépôt béni.

Ceux qui sont plus à l'aise avec un modèle push voudront peut-être mettre en place un référentiel de stockage local à chaque emplacement, à côté de la réplique, par exemple hg-stage.duke.mx, hg-stage.duke.cn, etc. Cela nécessite un peu plus de travail, cependant, comme les développeurs doivent non seulement fusionner avec d'autres modifications locales, mais quelqu'un doit être responsable de la fusion des modifications du référentiel de transfert dans le dépôt béni. Cela peut cependant fonctionner dans les bonnes circonstances et peut être facilité par l'automatisation.

"Transparence"

Passons maintenant à la question de la réplication transparente.

Compte tenu des scénarios ci-dessus, je ne vois pas vraiment la nécessité d'une réplication transparente. Tous les dépôts sont visibles par tout le monde, et il existe des conventions pour extraire / cloner de la réplique locale et pousser vers un référentiel béni ou une zone de stockage locale.

Si vous voulez de la transparence, vous pouvez demander à des personnes de configurer des domaines de recherche DNS en fonction de leur emplacement. La réplique locale et les dépôts de transfert seraient simplement appelés "hg" et "hg-stage" et la configuration DNS les résoudrait en hg.duke.cn et hg-stage.duke.cn pour les développeurs en Chine, et en conséquence pour développeurs dans d'autres endroits. Mais c'est un peu magique et peut être déroutant, et je ne pense vraiment pas que cela ajoute beaucoup.

J'espère que cela répond à votre question. J'ai pris un certain nombre de libertés avec la réponse, mais il me semble que votre situation pourrait être corrigée grâce à l'utilisation des techniques que j'ai décrites ci-dessus.