Migration transparente de Bitbucket vers Github: un guide étape par étape et des principaux plats – partie 1

Introduction

Dans le paysage en évolution rapide des logiciels aujourd’hui, les entreprises doivent constamment réévaluer leurs outils pour rester compétitifs. Cet article explique le parcours de la migration des référentiels de code de Bitbucket à GitHub pour un client d’entreprise, une université de premier plan en Australie, car GitHub a de meilleures fonctionnalités collaboratives, des intégrations plus lisses et un écosystème adapté aux développeurs. Avec 1 600 référentiels à migrer avec l’histoire intacte, les branches, les étiquettes et les métadonnées, la migration manuelle n’était pas une option. Par conséquent, un script bash personnalisé a été conçu pour automatiser complètement la migration. Ce blog examinera les difficultés rencontrées, les tactiques adoptées pour les surmonter et comment la migration a été effectivement mise en œuvre dans le calendrier convenu.

Déclaration de problème

Le client utilisait Bitbucket comme plate-forme de contrôle de version principale de plus de 5 ans, mais avait décidé de passer à GitHub pour profiter de ses fonctionnalités de collaboration améliorées, une intégration plus stricte avec des flux de travail CI / CD et un écosystème plus adapté aux développeurs.

Il y avait 1600 dépositions dans Bitbucket qui devaient être migrées vers GitHub.

Défis connus avant la migration:

Les principaux défis rencontrés:

1. Manque d’outils existants: la recherche d’outils de migration qui pourraient répondre aux spécifications a conduit à la déception car il n’y avait pas de correspondance directe. Cela a conduit à la création d’un script bash personnalisé pour les besoins de migration.
2. Différences de la structure du référentiel: Dans Bitbucket, les référentiels existent dans les projets; Dans GitHub, tous les référentiels doivent exister directement sous une seule organisation. La modification dynamique des URL de l’API a dû être effectuée pendant le processus de migration.
3. Différences de fonctionnalités et de format: certaines de ses fonctionnalités par exemple User Login Exp. Le client voulait avoir des utilisateurs gérés par l’organisation sur GitHub (SSO) avec une base d’utilisateurs gérée par l’entreprise. Sur Bitbucket, l’authentification des utilisateurs était basée sur le SSO traditionnel. Les groupes sur GitHub ont été synchronisés avec l’IDP, tandis que sur Bitbucket, l’accès a été géré au niveau du projet qui ne nécessitait pas nécessairement des groupes d’utilisateurs.
4. Préservation des métadonnées: Une partie critique de la migration était de garantir que l’historique, les branches et les étiquettes de chaque référentiel de chaque référentiel étaient transférés avec précision. Gérer cela tout en abordant les différences spécifiques à la plate-forme a nécessité une attention supplémentaire.
5. Changement dans les URL distantes: l’URL du référentiel a changé en raison de la migration, en particulier dans le code de bibliothèque partagé. Cela nécessite la suppression des dépendances au niveau du projet dans les bibliothèques JenkinsFile et partagées.

Travail de préparation

La faisabilité de la migration a été évaluée pour déterminer quelles caractéristiques doivent être migrées. La liste de contrôle est fournie ci-dessous.

liste de contrôle

Pour assurer une migration douce et réussie de référentiels de Bitbucket à Github, les étapes clés suivantes ont été suivies:

1. Création de repos.csv: un fichier repos.csv a été préparé comme entrée pour le script de migration, répertoriant les clés du projet et les noms de référentiel dans le format suivant: project_key, repo_name
2. Configuration du fichier variable.var qui est responsable du transport de certaines variables nécessaires pendant la migration.

Planification des migrations

Planification des migrations, développement de script et exécution – Équipe TTN

L’équipe TTN est responsable de la conception de la stratégie de migration, du développement des scripts d’automatisation requis et de l’exécution du processus de migration. Cela comprend:

1. Identifier les référentiels et définir l’approche de migration
2. Créer et tester les scripts de migration
3. Exécuter la migration d’une manière structurée et progressive

Examen et validation – Équipe client

L’équipe client vérifie tous les référentiels migrés et vérifie qu’ils sont corrects et inchangés. Les principaux domaines de travail sont:

1. Vérification de la structure du référentiel, de l’historique des engagements, des métadonnées
2. Protection des succursales et autorisation correcte
3. Trouvez des décalages et résolvez-les après la migration.

Une migration efficace nécessite une planification minutieuse pour assurer une transition fluide et réussie. Vous trouverez ci-dessous les étapes clés impliquées dans la phase de planification de la migration:

1. Préparer le fichier d’entrée: Créé list-list contenant des clés de projet et des noms de référentiel.
2. Pré-vérités: prechecks.script Les scripts vérifieront la présence de référentiels sur Bitbucket et GitHub avec leur état actuel et réduiront également les valeurs redondantes du fichier d’entrée créé.
3. Exécution de migration: getInventory.script Transfère les référentiels avec une histoire complète.
4. Autorisation de groupe: getbitbucketperm.script & MAPPERMGHUBUB.Scriptus Scripts pour récupérer et mapier les autorisations de groupe BitBucket à GitHub.
5. Branche par défaut: Récupéré et définir la branche par défaut dans github en utilisant defaultBranch.script.
6. Règles de protection des succursales: brprotectle.script Applique les règles de protection de la branche après la définition de la branche par défaut.
7. Mise à jour de l’URL du sous-module: updatesubmodurl.script Applique des liens sous-modules pour référence aux référentiels GitHub.
8. Mise à jour de l’URL de Jenkins: Modifications de Jenkins appliquées et modifications de l’URL du référentiel entre les mises à jour de repo en utilisant updatejfrepourl.script
9. Rapport post-migration: Généré un rapport pour identifier les incohérences et vérifier le succès de la migration en utilisant migrationReport.script
10. Vérifiez les écarts / corrects sur les problèmes: Examiné et résolu tout problème du rapport de migration. validatemimigration.script
11. Archive GitHub Repositaires: Archivé des référentiels migrés avec succès après validation archivegithub.script

Diagramme d’écoulement d’exécution

Diagrammes d’écoulement d’exécution

Flux de travail de migration

Le processus de migration du référentiel a été soigneusement structuré pour garantir la cohérence, la précision et les perturbations minimales. Voici un aperçu de haut niveau des étapes impliquées, qui peuvent être visualisées dans le diagramme de flux d’accompagnement:

1. Sélection du référentiel
   Nous avons commencé par finaliser la liste des référentiels qui devaient être migrés. Cela comprenait l’identification des référentiels entre les projets, à la fois actifs et hérités.
2. Mise à jour variable de l’environnement
   Les variables d’environnement ont été mises à jour pour refléter les informations d’identification et configurations nécessaires requises pour la migration transparente.
3. Exécution du script de migration
   Un script personnalisé (migraterepo) a été exécuté pour gérer la migration réelle. Le script a conservé la structure et les métadonnées du répertoire existant de chaque référentiel.
4. Gestion du projet hérité
   Si un référentiel appartenait à un projet hérité, il a été migré vers GitHub.Archivéd Post-Migration dans GitHub. Le référentiel Bitbucket d’origine était également archivé. Si le référentiel ne faisait pas partie d’un projet hérité, nous avons procédé à d’autres mises à jour
5. Mises à jour post-migration pour les référentiels actifsVérification du module: Nous avons vérifié si le référentiel contenait des sous-modules.
   Si des sous-modules étaient trouvés, leurs URL ont été mises à jour en conséquence.Projets GO: Pour les référentiels basés sur GO, nous avons fait des mises à jour vers Go.mod et d’autres fichiers pertinents pour refléter les nouveaux chemins de bibliothèque ou les dépendances après la migration.
6. Comparaison des stocks
   Après la migration et les mises à jour, nous avons comparé l’inventaire du référentiel GitHub avec l’inventaire Bitbucket d’origine pour identifier les écarts et assurer l’exhaustivité.
7. Traitement par lots
   Si davantage de référentiels étaient en attente, le processus ci-dessus a été répété pour le prochain lot. Ce cycle s’est poursuivi jusqu’à ce que tous les référentiels soient migrés avec succès et vérifiés.

Schéma d’architecture

Schéma d’architecture

Exécution transparente:

Avec environ 1 600 référentiels à migrer, le processus a été divisé en trois lots gérables.

1. Lot 1: Le premier lot comprenait des référentiels moins complexes pour une migration initiale plus lisse.
2. Lot 2: Faire face à des référentiels plus complexes qui impliquent des considérations supplémentaires.
3. Lot 3: A résolu les autres référentiels en fonction des informations des lots précédents.

Note: Un sujet dans GitHub a été ajouté, en suivant le nombre de référentiels migrés. Le workflow n’incorpore pas de réutilisation des LF Git, des références ou des difficultés supplémentaires.

En fin de compte, la migration a été un succès, tous les référentiels ont réussi à passer à Github.

Dans la prochaine partie de cette série de blogs, nous plongerons plus profondément dans le Défis auxquels nous avons été confrontésle impact cette migration Nous avions, et le Leçons que nous avons apprises En cours de route – ainsi que le meilleures pratiques Cela nous a aidés à garder les choses lisses et évolutives.

Vous avez trouvé cela utile? PARTAGEZ-LE