Je pense être arrivé à une solution plus ou moins satisfaisante pour le Projet 19 - "Documenter une méthode pour synchroniser un monorepo vers des multirepos qui fonctionne dans les deux sens".

Voici-ci, ci-dessous, les étapes de la démonstration qui sont détaillées dans le README.md du repository poc-git-monorepo-multirepos-sync.

Je crée deux repositories : frontend et backend (multi repositories) ;
J'utilise le script tomono pour les intégrer dans un monorepo nommé monorepo ;
J'ajoute deux fichiers à la racine de monorepo : README.md et .mise.toml ;
J'effectue des changements dans le repository frontend, je commit ;
Je pull les changements du repository frontend vers monorepo ;
Dans monorepo, j'effectue des changements dans le dossier frontend/, je commit ;
J'utilise cd frontend/; git format-patch --relative -1 HEAD pour générer un patch qui contient les changements que j'ai effectués dans le dossier frontend/ ;
Je vais dans le repository frontend et j'applique les changements contenus dans ce patch avec la command git apply monpatch.patch ou avec git am monptach.patch.

Pour le moment, j'ai privilégié l'option git patch, parce que je souhaite suivre la méthode la plus "manuelle" que j'ai pu trouver lorsque je dois intervenir sur les repositories upstream, parce que je ne veux prendre aucun risque de perturber mes collègues avec mon initiative de monorepo.

Le repository GitHub suivant contient le résultat final du monorepo : https://github.com/stephane-klein/poc-git-monorepo-multirepos-sync-result-example/.

Est-ce que je suis satisfait du résultat de cette démo ?

La réponse est oui, bien que je ne sois pas satisfait de quelques éléments.
Par exemple, les fichiers de frontend présents dans ce commit ne sont pas dans le dossier frontend. J'aimerais que ces titres de commits contiennent un prefix [frontend] ... et [backend].... Je pense que cela doit être possible à implémenter en modifiant le script tomono.

Est-ce que c'est pénible à utiliser ? Pour le moment, ma réponse est « je ne sais pas ».

Je vais tester cette méthode avec deux projets. Je pense écrire une note de bilan de cette expérience d'ici à quelques semaines.

Ce mois de janvier est riche en article au sujet des Monorepo !

#JaiLu le contre pied du l'article "Monorepos: Please don’t" : Monorepo: please do! !

As a leader, I’ll pick the monorepo every time: because tools must reinforce the culture I want, and culture comes from the tiny decisions and behaviors of a team every day.

source

👌

Son thread Hacker News : 161 commentaires.

#JaiLu ce thread Hacker News au sujet des Monorepo : "Monorepos and the Fallacy of Scale | Hacker News".

J'ai trouvé l'article très intéressant ainsi que les commentaires.

#JaiLu ce thread Hacker News au sujet des Monorepo : "Monorepos: Please don’t".

Il contient de très bons commentaires biens argumentés qui expliquent les avantages des Monorepo, j'ai trouvé cela passionnant 🙂.

Au début, j'avais une sorte de jouissance à créer des dépôts pour chaque service de mon projet (je précise que tout seuls, ils ne servent à rien), j'avais l'impression d'être un bon élève. Mais, que c'est pénible d'en maintenir une cohérence ! Je suis plus heureux en Monorepo.

-- Témoignage d'un ami

Confusion à ne pas faire « Monolith ≠ Monorepo :

Monolith

Monolith ≠ monorepo. Monolith is huge amount of coupled code of 1 application that is hell to maintain.

source

Un projet en microservice peut très bien être hébergé dans un Monorepo.

J'ajoute aussi Multirepos ≠ microservices.

Il est tout à fait possible — voire courant — d'héberger un Monolith dans plusieurs repositories, mais d'après mon expérience, cela s'avère peu pratique, je peux même dire, pénible !

#JaiDécouvert le site "Advantages of monorepos" (https://danluu.com/monorepo/).

Avantages :

« Simplified organization » 👌
« Simplified dependency management » 👌
« atomic changes » 👌
« Extensive code sharing and reuse » 👌
« Unified versioning, one source of truth » 👌
« Code visibility and clear tree structure providing implicit team namespacing » 👌
« Large-scale refactoring » 👌
« Collaboration across teams » 👌

J'ai été perturbé par le contenu des slides « Monolithic repositories vs. Many repositories » de Fabien Potencier : https://speakerdeck.com/fabpot/a-monorepo-vs-manyrepos (voir 2017-12-03_1217).

J'ai continué à étudier le sujet des Monorepo et j'ai commencé à migrer un side project vers ce pattern. Pour le moment, l'expérience est très agréable. Je pense que je vais continuer dans cette direction.

#JaiLu les slides « Monolithic repositories vs. Many repositories » de Fabien Potencier : https://speakerdeck.com/fabpot/a-monorepo-vs-manyrepos.

#JaiDécouvert l'outil Git Subtree Splitter (https://github.com/splitsh/lite).

Voir aussi Multirepos.

https://danluu.com/monorepo/

Date de la création de cette note : 6 décembre 2024.

Quel est l'objectif de ce projet ?

En décembre 2017, convaincu par les avantages du modèle Monorepo, j'ai effectué un véritable changement de paradigme en abandonnant le modèle Multirepos.

Depuis, je n'ai eu aucun regret. J'utilise le modèle Monorepo dans tous mes projets, car il simplifie énormément la plutpart des workflow, notamment l'onboarding, grâce à des kits de développement simplifiés.

Cependant, le modèle Multirepos est très populaire, je le rencontre partout où j'interviens.
Cela me perturbe beaucoup, car je constate à chaque fois que ce modèle complique tout. L'onboarding, le flux de travail, de déploiement, la documentation…

L'objectif de ce projet est de documenter une méthode et des outils qui me permettent de maintenir en douceur, sans rien imposer, un monorepo qui contient un development kit de qualité, agréable à utiliser.

Je souhaite pouvoir travailler dans ce monorepo tout en envoyant mon travail dans des branches sur les multi repositories d'origine.

Je souhaite aussi pouvoir pull les changements des multi repositories vers mon monorepo.

Ces deux user stories me permettront d'améliorer le monorepo sans modifier le workflow de développement des autres membres de l'équipe.

Une fois le kit de développement du monorepo opérationnel, je pourrai présenter ce projet à l'équipe pour leur en montrer le fonctionnement, les avantages, ainsi que sa simplicité d'utilisation et d'onboarding.

Au final, il reviendra à l'équipe de décider si elle souhaite adopter ce paradigme ou non.

Repository de ce projet :

https://github.com/stephane-klein/poc-git-monorepo-multirepos-sync

Ressources :