Fusion de dora-back et dora-front en un monorepo dora

[ggounot]

🍣 Contexte / problème

💡 Cette pull request est la mise en œuvre de l'ADR pour passer d'un multirepo (front + back) à un monorepo.

Cette PR fusionne les dépôts dora-back et fora-front dans un seul dépôt unifié dora.

🍔 Solution / réalisation

🏁 TL;DR

• Fusion des historiques de commits avec le contenu de dora-back dans le répertoire back et le contenu de dora-front dans front ;
• Copie de la configuration dependabot du back avec ajout de configuration pour le front ;
• Intégration des workflows GitHub de CI du back et du front ;
• Mise à jour du script post_compile pour prendre en compte le sous-répertoire back pour Scalingo ;
• Mise à jour du script release.sh ;
• Mise à jour du fichier README.md.

🏺 Import et fusion des entrepôts dora-back et dora-front

🔑 Nous avons utilisé la commande git subtree. Celle-ci permet d’ajouter le contenu d’un autre repository dans un sous-dossier sans perturber l’historique ni provoquer de conflits avec l’existence d’un dossier .git ou .gitignore.

# Récupération du dépôt "dora" afin de réaliser les opérations en local
git clone https://github.com/gip-inclusion/dora.git
cd dora

# Création d'une branche de travail temporaire
git checkout -b temp-branch

# Import des sources et commits de "dora-back" (via la commande "git subtree")
git remote add dora-back https://github.com/gip-inclusion/dora-back.git
git fetch dora-back
git subtree add --prefix=back dora-back main

# Idem pour "dora-front"
git remote add dora-front https://github.com/gip-inclusion/dora-front.git
git fetch dora-front
git subtree add --prefix=front dora-front main

# Vérification de l'historique
git log --all --graph --oneline --decorate

# Publication de la branche sur GitHub (avec création de cette PR)
git push

🤖 Dependabot

Nous avons repris la configuration Dependabot de dora-back, que nous avons enrichi au passage pour la partie front.

Il a suffit de déplacer le fichier ~/back/.github/dependabot.yml pour le remonter à ~/.github/dependabot.yml en y ajoutant une section dédiée à npm (pour le front Sveltekit).

🏭 CI / GitHub Actions

Nous avons décidé de créer 2 fichiers :

• ~/.github/workflows/back-ci.yml pour le back
• ~/.github/workflows/front-ci.yml pour le front

La plus gros de la manœuvre a été de préfixer certains chemins en fonction de l'app (/front ou /back).

Nous avons privilégié l'emploi de la propriété working-directory plutôt que l'emploi de la commande cd [back|front].

🔥 Nous avons rencontré un souci d'exécution des workflows. Cela tenait au fait que l'option "Allow only organisation actions to execute" était coché. Nous avons opté pour l'option "Allow organisation and GitHub actions to execute".

⚙️ Scalingo

Côté Scalingo, il a suffi, dans un premier temps, d'ajouter aux 2 applications staging la variable d'environnement PROJECT_DIR spécifiant le répertoire concerné (back ou front) :

• dora-back-staging : PROJECT_DIR=back
• dora-front-staging : PROJECT_DIR=front

Nous avons rencontré une grosse résistance pour l'application back, car il y avait un script bin/post_compile (étape post compile dans le buildpack lifecycle).

La solution était toute simple : il suffisait d'indiquer le sous-répertoire /back dans le script.

Nous en avons profité pour améliorer un tantinet ledit script pour coller un peu plus aux bonnes pratiques de rédaction d'un script shell.

⚠️ Il faudra ajouter les mêmes variables pour les applications de production avant le déploiement du dépôt unifié !

🎁 Script de release

La modification du script a été assez simple. Nous avons simplement supprimé les paramètres possibles et nous sommes contentés d'appeler la méthode deploy_repo() avec le paramètre "dora".

🧹 Issues et Pull requests

Par chance, les issues n'étaient pas utilisées sur les dépôts dora-back et dora-front.

Pour ce qui est des pull requests, dans la mesure où il y en avait peu, nous avons pris le parti de les refaire à la main, en réimportant les branches associées.

⚠️ Après discussion, il nous est apparu plus simple et fiable de d'abord fusionné cette pull request et la nouvelle architecture monorepo, avant de songer à importer les branches des anciens dépôts.

# Exemple d'import de la branche dora-back de migration de Inclusion Connect vers Pro Connect (dora-back/pro-connect-migration)
git subtree pull --prefix=back https://github.com/gip-inclusion/dora-back.git pro-connect-migration

Cette commande crée un commit de merge. Nous avons cherché à nous en passer, mais ça semblait compliqué ou bancal. Nous avons sacrifié la perfection de l'historique Git sur l'hôtel du pragmatisme opérationnel.

Les descriptions et discussions ont été recopiées manuellement, avec mention des PR originales.

⏰ Organisation

Nous avons décidé de ne pas nous précipiter et fusionner / livrer le tout, tout de suite. Nous avons préféré attendre le lendemain midi, frais et requinquer, avant d'intégrer et pousser en prod ce gros changement.

🍻 Post-merge (23/10/2024)

Pour mettre en production la nouvelle organisation de code, nous avons :

• ajouté les variables d'environnement PROJECT_DIR aux applications de production sur Scalingo
• mis à jour les associations GitHub dans la partie "Deploy (via GitHub)" de Scalingo
• créé la branche dora/releases
• mise à jour des variables d'environnement Scalingo dans Bitwarden
• mise à jour des PR référencées par les cartes Trello

[ggounot]

Mono repo

[jbuget]

We did it ! LGTM 🚀