Retour d’expérience sur l’adoption d’un Monorepo par l’équipe de développement de l’API Airbridge

Présentation des raisons qui ont conduit l’équipe de développement de l’API Airbridge à adopter un Monorepo, ainsi que de cas concrets de résolution des problèmes rencontrés lors de sa mise en place.

• Contexte de l’adoption du Monorepo
  • Qu’est-ce qu’un Monorepo ?
  • Pourquoi l’équipe API d’Airbridge l’a adopté
• Objectifs du projet
  • Introduire un dépôt Monorepo tout en conservant la même expérience de développement
• Problèmes identifiés après la mise en œuvre
  • Pendant le processus CI/CD, le fait de devoir déterminer si chaque composant avait subi des modifications a rendu les scripts CI/CD plus complexes et a entraîné des problèmes, comme l’impossibilité de redéployer le même code
• Pour y remédier
  • Introduction d’un composant chargé de déterminer à l’avance si un composant a été modifié avant l’exécution du CI/CD, afin de déclencher ensuite le CI/CD (Code Deployer)
• Pour aller plus loin
  • Permettre de vérifier le CI dans les PR
  • Améliorer la visibilité des informations de PR et de l’état du CI dans Slack
• Après l’adoption du Monorepo
  • Meilleure visibilité sur les composants pris en charge
  • Gain de productivité
• Conclusion