Migrer une base de code Rails de GitLab vers GitHub sans casser le CI/CD

Déplacer un dépôt Rails de GitLab vers GitHub ressemble à un simple push vers un nouveau remote. Le vrai travail, c'est tout ce qui n'est pas le code : la CI, l'historique des merge requests, les webhooks et la dizaine d'intégrations discrètement liées à des comportements propres à GitLab.

L'historique git est la partie facile

git clone --mirror git@gitlab.example.com:team/app.git
cd app.git
git remote set-url --push origin git@github.com:team/app.git
git push --mirror

Les branches, les tags et l'historique des commits passent sans problème. Ce qui ne suit pas : les discussions des merge requests, les approbations et l'historique des jobs de CI. Rien de tout cela ne vit dans le graphe d'objets git, et GitLab et GitHub n'ont pas de format d'export commun pour ces données.

Réécrire la CI est le vrai projet

GitLab CI et GitHub Actions partagent beaucoup de concepts, jobs, stages, cache, mais pas la syntaxe, et certaines fonctionnalités natives de GitLab n'ont pas d'équivalent direct dans Actions. Nous traitons cela comme une réécriture, pas comme une traduction, et nous faisons tourner les deux pipelines en parallèle sur la même branche pendant quelques semaines avant de basculer, en comparant les résultats job par job.

Les règles de protection des branches ne se transfèrent pas toutes seules

Les approbations requises, les status checks obligatoires et les restrictions de merge doivent tous être recréés à la main dans les paramètres de GitHub, et il est facile de les sous-spécifier la première fois. Avant la bascule, nous écrivons explicitement le jeu de règles cible sous forme de checklist, plutôt que de le reconstituer de mémoire à partir d'une configuration GitLab vieille de plusieurs mois.

Webhooks et intégrations : à auditer avant, pas après

Chaque outil externe branché sur le projet GitLab, déclencheurs de déploiement, notifications de chat, intégration de page de statut, a besoin de son équivalent configuré sur GitHub avant que l'ancien dépôt ne soit archivé. Nous commençons par un audit complet des webhooks et des intégrations du projet GitLab, nous migrons chacun d'eux de façon délibérée, et nous n'archivons le projet GitLab que lorsque plus rien ne pointe vers lui.

La migration en elle-même prend un après-midi. S'assurer que rien n'a cessé de fonctionner en silence prend les deux semaines qui l'entourent, et c'est cette partie qui mérite d'être planifiée.