Je voudrais savoir s'il est judicieux de diviser le projet sur lequel je travaille en deux référentiels au lieu d'un.
D'après ce que je peux dire:
- Le frontend sera écrit en html + js
- Backend en .net
- Le backend ne dépend pas du frontend et le frontend ne dépend pas du backend
- Le frontend utilisera une api reposante implémentée dans le backend.
- Le frontend peut être hébergé sur n'importe quel serveur http statique.
Pour l'instant, le référentiel a cette structure:
racine:
- l'extrémité avant/*
- backend / *
Je pense que c'est une erreur de garder les deux projets dans le même référentiel. Étant donné que les deux projets n'ont pas de dépendances entre eux, ils doivent appartenir à des référentiels individuels et, si nécessaire, à un référentiel parent contenant des sous-modules.
On m'a dit que c'était inutile et que nous n'en tirerions aucun avantage.
Voici certains de mes arguments:
- Nous avons deux modules qui ne dépendent pas l'un de l'autre.
- A long terme, l'historique des sources des deux projets peut compliquer les choses (essayez de rechercher dans l'histoire quelque chose dans le frontend pendant que vous avez la moitié des validations qui ne sont absolument pas liées au bogue que vous recherchez)
- Conflit et fusion (cela ne devrait pas se produire, mais le fait de demander à quelqu'un de pousser vers le backend forcera les autres développeurs à effectuer des changements de backend pour pousser les changements de frontend.)
- Un développeur peut travailler uniquement sur le backend mais devra toujours tirer le frontend ou l'inverse.
- À long terme, quand il sera temps de se déployer. D'une certaine manière, le frontend pourrait être déployé sur plusieurs serveurs statiques tout en ayant un seul serveur backend. Dans tous les cas, les utilisateurs seront obligés soit de cloner l'intégralité du backend avec, soit de créer un script personnalisé pour envoyer uniquement à tous les serveurs le frontend ou pour supprimer le backend. Plus facile de simplement pousser / tirer uniquement le frontend ou le backend que les deux si un seul est nécessaire.
- Contre-argument (une personne peut travailler sur les deux projets), créer un troisième référentiel avec sous-module et développer avec lui. L'historique est conservé séparément dans les modules individuels et vous pouvez toujours créer des balises où la version du backend / frontend fonctionne vraiment ensemble en synchronisation. Avoir les deux frontend / backend ensemble dans un même dépôt ne signifie pas qu'ils fonctionneront ensemble. C'est juste fusionner les deux histoire en un seul grand repo.
- Avoir frontend / backend comme sous-modules facilitera les choses si vous souhaitez ajouter un pigiste au projet. Dans certains cas, vous ne voulez pas vraiment donner un accès complet à la base de code. Avoir un gros module rendra les choses plus difficiles si vous voulez restreindre ce que les "étrangers" peuvent voir / modifier.
- Introduction et correction de bug, j'ai inséré un nouveau bug dans le frontend. Ensuite, quelqu'un corrige un bug dans le backend. Avec un référentiel, la restauration avant le nouveau bogue entraînera également la restauration du backend, ce qui pourrait rendre sa correction difficile. Je devrais cloner le backend dans un dossier différent pour que le backend fonctionne tout en corrigeant le bogue dans le frontend ... puis en essayant de remettre les choses au point ... Avoir deux référentiels sera indolore car déplacer le HEAD d'un repo a gagné ne change pas l'autre. Et les tests avec différentes versions de backend seront indolores.
Quelqu'un peut-il me donner plus d'arguments pour les convaincre ou au moins me dire pourquoi il est inutile (plus compliqué) de diviser le projet en deux sous-modules. Le projet est nouveau et la base de code date de quelques jours, il n'est donc pas trop tôt pour le réparer.