Méthode d'intégration de différents systèmes de contrôle de version ou de choix de l'un par rapport aux autres, en raison de fusions et d'acquisitions?

11

Les sociétés acquièrent d'autres sociétés qui utilisent différents systèmes de contrôle de version.

Y a-t-il une sagesse commune sur la façon d'intégrer de tels systèmes ensemble, par exemple en utilisant un pont Subverson-GIT ou même de décider d'utiliser un seul outil sur un autre - et comment migrer entre les systèmes?

Les gens utilisent-ils un ensemble de critères pour une telle prise de décision, par exemple un équivalent au test "Joel" sur le développement de logiciels?

version-control migration

— therobyouknow
source

11

Pour répondre à la question de la migration à partir de l'expérience personnelle de plusieurs migrations:

N'ayez pas peur de simplement mettre la version actuelle du logiciel dans le nouveau système de contrôle de source comme ligne de base et de travailler à partir de là.

La grande majorité du temps, vous n'aurez pas besoin de l'historique. Cela signifie que c'est une tâche de moins à effectuer pendant l'intégration et une chose de moins à se tromper.

Les fichiers / projets en développement actif vont bientôt générer une nouvelle histoire. Ainsi, lorsque vous devez savoir pourquoi un changement a été effectué, il est probable que l'historique se trouve dans le référentiel actuel, car il s'agit d'un changement récent.

Les fichiers / projets qui étaient stables avant la migration devraient (toutes choses étant égales par ailleurs) rester stables après la migration, vous n'aurez donc pas besoin de vous référer à l'historique. Nous avons constaté que si nous devions enquêter sur un bogue dans un fichier ou un projet aussi ancien, l'historique n'avait vraiment aucun avantage. Tant que vous gardez l'ancien référentiel disponible pendant 6 mois / an, vous aurez la référence dans de tels cas.

— ChrisF
source

+1 juste point, migrez uniquement ce dont vous avez besoin, laissez les anciennes versions dans l'ancien référentiel hérité. Ne migrez pas pour lui-même. Cette approche est une variante de l'approche du choix entre l'organisation et la recherche. Si la recherche peut vous fournir ce que vous voulez rapidement, à chaque fois il n'est pas nécessaire d'organiser ce que vous recherchez.

— therobyouknow

1

+1 IMO la meilleure stratégie. Continuez à utiliser un seul, les autres en mode lecture seule au cas où.

— user281377

1

+1: réponse plus précise sur la partie migration.

— VonC

1

+1 - assez difficile pour comprendre le code existant et encore moins les trois dernières versions.

— JeffO

1

Nous avons converti de nombreux référentiels CVS en SVN en utilisant le script cool cvs2svn, qui fonctionnait très bien. Je ne me souviens jamais d'avoir regardé l'histoire au-delà des «changements récents», donc cela ne valait pas vraiment l'espace disque. Si je le faisais à nouveau, je baliserais simplement le dépôt CVS, m'enregistrerais dans SVN comme nouveau, puis marquerais le dépôt CVS en lecture seule.

— JBRWilkinson

4

Du côté managérial, il s'agit principalement de:

support : l'entreprise qui sortira le VCS sera-t-elle toujours là en cas de problème.
C'est malheureusement l'une des principales raisons pour lesquelles de tels produits obsolètes comme ClearCase sont toujours pris en compte (ClearCase étant depuis 2003 un ... produit IBM )
Coût de la licence : même s'il existe des alternatives gratuites, parfois des "licences de groupe" pour un VCS peuvent être négociées ou réellement incluses dans un contrat beaucoup plus important comprenant des serveurs, des réseaux, du support, etc ... Une licence globale pour ce type de produit peut prendre fin jusqu'à coûter beaucoup moins que le prix public.

Côté projet, il s'agit aussi de:

administration : sur quel serveur allez-vous installer un VCS (ou de nombreux VCS si nous parlons de Git, SVN et autres)? Avec quelle politique de sauvegarde? Quel DRP (Disastry Recovery Plan)?
support local : qui prendra le support de niveau 1 ,? niveau 2?
connaissance du marché : êtes-vous sûr de trouver suffisamment de développeurs et / ou d'administrateurs possédant les connaissances nécessaires pour tirer parti de ce VCS et de toutes ses fonctionnalités?

Freeware ou pas, rappelez-vous qu'un logiciel "gratuit" est gratuit comme dans "Free Speech" (vous êtes libre de choisir et de déployer celui que vous voulez), pas comme dans "Free Beer" (cela coûtera toujours beaucoup d'argent sur le serveur). , sauvegarde, administration, support, ...)

Les critères mentionnés ci-dessus sont un début pour déterminer quel VCS garder, quoi abandonner.
Mais dans ce dernier cas, vous devez considérer:

stratégie de migration : pouvez-vous exporter / importer un historique de projet d'un VCS à un autre?
stratégie de pont : est-il judicieux d'avoir une histoire dans deux VCS différents?
obsolescence du projet : si un projet est en état de maintenance / fin de vie, il peut être préférable de prendre en charge un ancien VCS pendant une courte période.

— VonC
source

+1 bonne réponse, les puces décrivent les critères que je recherche, et vos explications avec eux aident aussi. Je donnerai une chance aux autres avant d'accepter une réponse. Merci.

— therobyouknow

1

Avez-vous vraiment besoin d'intégrer différents systèmes? Dans notre équipe, chaque projet vit dans son propre référentiel, et leurs histoires sont donc indépendantes. Nous n'avons aucun problème ici à travailler avec certains projets en subversion et d'autres sous mercurial, même s'il y a des dépendances entre eux.

Si vous choisissez de migrer d'un VCS à un autre, regardez les outils de conversion disponibles. D'après mon expérience, il n'y a aucune raison technique de laisser tomber l'historique des projets.

Éditer

Je pense avoir compris quelque chose, qui était implicite dans la question et dans d'autres réponses. C'est le fait que VCS est également utilisé pour gérer les dépendances. Je sais qu'il est assez courant d'utiliser des fonctionnalités VCS comme svn:externalspour intégrer un dépôt (la dépendance) à un autre.

Je pense que la raison (technique) pour laquelle notre équipe ne ressent pas le besoin de relier (ou d'intégrer) nos 2 systèmes différents est que nous avons un outil séparé pour gérer les dépendances. Notre repo ne se connaît pas.

— barjak
source

Besoin d'intégrer différents systèmes? Oui si le travail d'une équipe est utilisé par une autre équipe. L'intégration peut être serrée ou perdue selon le niveau de nécessité et les ressources en personnel disponibles. Non si les projets sont totalement indépendants. La seule préoccupation qui reste est de soutenir plus d'un système et de savoir si cela est perçu comme une bonne ou une mauvaise chose. Bon si nous acceptons que nous vivons dans un monde informatique varié ou mauvais si nous pensons que nous devons nous concentrer et faire preuve de détermination pour eux-mêmes, en choisissant un outil lui-même qui pourrait être trop solipstiste!

— therobyouknow

PS. +1 Heureusement, barjak, d'être dans une organisation qui tolère un environnement informatique varié.

— therobyouknow

0

Beaucoup de bonnes réponses. Une autre chose à penser est de ne pas laisser les membres de l'équipe s'en tirer en pensant que changer de VC est un gros problème. Il y aura un revers avec la migration, une courbe d'apprentissage, etc., mais s'ils ont trop de problèmes, ils doivent remettre en question leur niveau de capacité et / ou de coopération.

— JeffO
source

+1 Un réalisme ici. Les gens doivent garder leur sang-froid, être courageux et continuer. Les risques doivent être bien définis. L'un des apprentissages que je vois et que j'entends dire sur mon lieu de travail, c'est que parfois nous ne travaillons pas assez dur pour réduire l'incertitude / définir clairement les risques / contingences avant de nous engager. Il semblerait qu'il y ait beaucoup de temps pour l'itération de correction / correction, mais pas assez de temps pour faire les choses correctement la première fois. La résolution des problèmes est récompensée et considérée comme une activité en cours, même si parfois elle n'était pas nécessaire.

— therobyouknow

1

Cela dépend des VCS en question et de la qualité de la migration. Passer de Git ou même CVS à n'importe quel VCS de verrouillage va être extrêmement discordant.

— David Thornley