J'ai remarqué que je développe un FW Java dans le référentiel mono, donc je vais considérer l'opération.

introduction

Cet article est un article qui considère le fonctionnement du référentiel pour profiter des mérites du développement monorepo dans un projet de développement de Java FW.

Qu'est-ce que Monorepo?

En termes simples, il s'agit d'une stratégie d'opération de référentiel qui gère le code entre les modules dans un référentiel. Il existe deux façons de penser à monorepo, mais dans cet article, nous examinerons la ** dernière **.

1. L'idée de gérer tout le code d'entreprise dans un seul référentiel
2. L'idée de gérer tout le code d'un module de projet dans un référentiel

S'agit-il d'un repo mono?

Mon équipe développe Java FW. Le FW se composait de plusieurs modules, qui ont été développés dans un référentiel Git. Après avoir confirmé les circonstances avec l'équipe, il a été dit que le référentiel avait été créé dans le cadre de l'assurance qualité en tant que produit. À ce moment-là, j'avais peu d'expérience avec Git, donc je ne me sentais pas mal à l'aise, mais il semble que le fonctionnement d'un tel référentiel s'appelle monorepo, donc je vais examiner si c'est une opération qui utilise les mérites de l'opération monorepo.

Avantages de Monorepo

Si vous vous référez au document de Nx, qui est un ensemble d'outils pour le développement monorepo, les quatre points suivants peuvent être mentionnés comme les mérites du fonctionnement monorepo.

1. Le code est facile à réutiliser car tout le code est dans le même référentiel et peut être référencé l'un par rapport à l'autre.
2. L'impact des modifications de module est complet dans le même référentiel et peut être résolu avec 1PR.
3. Procédures de construction et de test cohérentes pour les modules utilisant différents outils et technologies.
4. Les dépendances de chaque module peuvent être fixées à un seul ensemble, et vous ne serez pas dérangé par les conflits de dépendances plus tard.

Revenez sur le référentiel Java de l'équipe

À partir des deux points suivants, on peut dire que le référentiel profite des avantages de monorepo. En fait, nous ne lançons pas de relations publiques dans divers référentiels lorsque nous développons et modifions des fonctions, et nous n'avons pas à nous soucier des dépendances comme test de consolidation.

1. Les modules qui composent le produit sont gérés dans le même référentiel

Les modules, y compris le code de test, sont développés dans le même référentiel, et vous pouvez vous référer les uns aux autres et vérifier l'impact des changements (* La structure de l'image est une image). Si le référentiel contient un fichier qui définit un travail de pipeline (.gitlab-ci.yml), tel que GitLab CI / CD, le pipeline Un autre avantage est que les travaux peuvent être facilement réutilisés.

2. Les dépendances sont gérées de manière unique dans le fichier gradle

Les dépendances de produit sont gérées dans un seul fichier gradle.

dependencies {
	implementation("org.aspectj:aspectjrt:1.9.4")
	implementation("org.aspectj:aspectjweaver:1.9.4")
	implementation("com.fasterxml:classmate:1.4.0")
	implementation("commons-beanutils:commons-beanutils:1.9.3")
	implementation("commons-betwixt:commons-betwixt:0.8") {
		exclude module: "commons-beanutils-core"
	}
    //Omission
}

Fonctionnement du mono repo

Comme mentionné ci-dessus, nous avons pu confirmer que l'équipe bénéficiait du mono repo. Ensuite, réfléchissons aux considérations relatives au fonctionnement de monorepo afin de maximiser les avantages de monorepo et de résoudre les problèmes opérationnels de monorepo. Ceci est basé sur les références. Voir aussi les références à la fin de cet article.

** 1. Comment gérer l'augmentation de la taille du référentiel physique ** Le référentiel est gonflé car tout le code est géré dans un seul référentiel. Sans parler de la taille, vous devriez envisager de gérer l'augmentation du temps de construction et de test. En général, il contrôle de construire et de tester uniquement la zone d'influence.

** 2. Comment protéger les modules que vous ne souhaitez pas falsifier ** Si tous les modules sont stockés dans un seul référentiel, une autre équipe peut les détruire. Considérer la fourniture de contrôle pour chaque équipe pour le module.

** 3. Dans quelle mesure une norme unique peut-elle pénétrer chaque module ** Si le style de codage, les normes de contrôle qualité et les ensembles de dépendances sont différents pour chaque module, les avantages de monorepo seront perdus et la gestion deviendra compliquée. La solution de contournement consiste à appliquer la norme de facto sur le module.

** 4. Les modifications de module peuvent-elles être rapidement diffusées dans tout le référentiel **? L'avantage du fonctionnement mono-repo est que tous les développeurs peuvent se référer au dernier code de tous les modules. Par conséquent, le développement basé sur le tronc basé sur CI / CD est préférable pour le fonctionnement du référentiel.

Retour sur le fonctionnement du référentiel Java de l'équipe

Par rapport au fonctionnement du mono repo, l'évaluation du fonctionnement du référentiel de l'équipe est la suivante.

1. Le référentiel et l'équipe de développement ne sont pas énormes.
2. En raison de la nature du projet, il n'est pas développé avec la participation de nombreuses équipes.
3. En tant que produit, un ** contrôle de qualité élevé ** est stipulé et certaines normes sont unifiées entre les modules.
4. Développé par la branche de fonctionnalité.

L'équipe accélère la réflexion sur les changements de code en promouvant CI / CD pour le contrôle qualité. De plus, on peut dire qu'il n'y a pas de problèmes dus à la taille du référentiel ou à l'ampleur du développement car les développeurs contrôlent l'ensemble du référentiel dans le développement avec un petit nombre d'équipes.

Résumé

Nous avons expliqué les mérites et le mode de fonctionnement du développement avec mono repo, et confirmé le mono repo de l'équipe et son fonctionnement. En conclusion, le référentiel de l'équipe n'avait pas de problèmes majeurs concernant le fonctionnement de monorepo, et il a été conclu que le développement progressait tout en bénéficiant des avantages. Dans un référentiel développé par une petite équipe, on peut dire qu'il n'y a pas beaucoup de problèmes causés par la réalisation d'un monorepo.

En passant, cela semble un peu étrange lorsque le référentiel et le référentiel sont alignés.

Les références

Concernant le mono repo, les mérites et les études opérationnelles sont décrits sur la base des références suivantes.

• Documentation Nx: https://nx.dev/angular/getting-started/why-nx
• Misconceptions about Monorepos: Monorepo != Monolith：https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c
• Traduction: https://www.graat.co.jp/blogs/ck1099bcoeud60830rf0ej0ix --Monolithe → MultiRepo → MonoRepo Stratégie de référentiel: https://slides.com/kotamat/repository-strategy