D'un seul dépôt, à plusieurs re-représentants, à monorepo, à multi-monorepo

L'évolution de ce projet reflète de nombreux voyages de développement de logiciels: démarrer simple, puis s'adapter à la complexité croissante. Initialement, une grande application monolithique dans un seul référentiel, elle a évolué à travers plusieurs étapes de refactorisation architecturale et de gestion du référentiel.

Étape 1: la simplicité du référentiel unique

Le projet Leoloso / Pop a commencé comme un site WordPress, combinant le thème et les plugins dans un seul référentiel. Cela a offert une facilité de développement initiale, mais est rapidement devenu difficile à manier car davantage de sites avec des fonctionnalités similaires ont été ajoutés. Le repo a grandi pour englober environ dix sites, créant un cauchemar de maintenance. La recherche et le remplacement des chaînes sur plusieurs sites se sont révélés incroyablement inefficaces.

Étape 2: Le défi multi-représentant

Pour résoudre les problèmes d'évolutivité, l'application a été refactorisée dans des packages PHP indépendants gérés par le compositeur. Cela a nécessité un passage à une structure multi-représentante, un référentiel par package. Tout en favorisant la réutilisabilité du code et une meilleure architecture, la gestion de plus de 200 référentiels est devenue extrêmement lourde. Les dépendances du versioning et la coordination des demandes de traction dans de nombreux référentiels se sont révélées incroyablement complexes. L'absence d'un système de gestion centralisé a entravé un développement efficace.

Étape 3: l'efficacité monorepo

La solution était un monorepo - un référentiel unique hébergeant tous les packages. Ce contrôle de version rationalisé, permettant des versions simultanées et des demandes de traction simplifiées. Cependant, comme Packagist nécessite des référentiels individuels pour l'édition de packages, une approche à deux volets a été adoptée: le monorepo pour le développement et les référentiels séparés pour la distribution. Cela a nécessité un processus pour "diviser" le monorepo, géré à l'aide de l'outil Monorepo Builder. Cette étape a considérablement amélioré la vitesse de développement, en particulier lors du refactorisation. La possibilité de publier plusieurs plugins WordPress simultanément via des workflows GitHub Actions personnalisés encore une efficacité améliorée.

Malgré ses avantages, le Monorepo a présenté des limitations: appliquer une licence unique sur tous les packages, gérer une grande carte d'émission et le versioning indépendant des packages même sans modifications de code.

Étape 4: La solution multi-monorepo

La nécessité de gérer le code public et privé a conduit à l'adoption d'une architecture multi-monorepo. Un monorepo public (Leoloso / POP) sert de référentiel en amont, tandis qu'un monorepo privé (Leoloso / GraphQlapi-Pro) agit comme un référentiel en aval, incorporant le public monorepo en tant que sous-module GIT. Cela permet au référentiel privé d'accéder et d'étendre la base de code public, permettant la génération de versions de plugin publiques et privées à l'aide d'un seul flux de travail adapté.

Cependant, cette approche introduit des complexités. Le référentiel en aval doit vérifier explicitement les sous-modules, nécessitant une gestion minutieuse des workflows et potentiellement des changements dans le référentiel en amont. Cela nécessite un examen et une communication soigneux du code minutieux pour éviter les conséquences involontaires.

Conclusion: un voyage en cours

L'évolution de la structure du référentiel de ce projet met en évidence l'importance de s'adapter aux besoins changeants. Chaque étape offrait des avantages et des inconvénients, conduisant finalement à une configuration multi-monorepo qui répond actuellement aux exigences du projet. Cependant, les besoins futurs pourraient nécessiter d'autres itérations dans la stratégie de gestion du référentiel. La «meilleure» approche reste dépendante du contexte, mettant l'accent sur la nature itérative du développement logiciel et de la gestion des référentiels.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!