Grande disposition de projet: ajout d'une nouvelle fonctionnalité sur plusieurs sous-projets

Je veux savoir comment gérer un gros projet avec de nombreux composants avec un système de gestion de contrôle de version.

Dans mon projet actuel, il y a 4 parties principales.

1. la toile
2. Serveur
3. Console d'administration
4. Plate-forme.

La partie web et serveur utilise 2 bibliothèques que j'ai écrites. Au total, il existe 5 référentiels git et 1 référentiel mercurial. Le script de construction du projet se trouve dans le référentiel Platform. Il automatise l'ensemble du processus de construction.

Le problème est que lorsque j'ajoute une nouvelle fonctionnalité qui affecte plusieurs composants, je dois créer une branche pour chacun des dépôts concernés. Implémentez la fonctionnalité. Fusionnez-le en arrière. Mon instinct est "quelque chose ne va pas".

Dois-je donc créer un seul dépôt et y mettre tous les composants? Je pense que la ramification sera plus facile dans ce cas. Ou je fais juste ce que je fais en ce moment. Dans ce cas, comment résoudre ce problème de création de branche sur chaque référentiel?

Dans la situation que vous décrivez, vous n'avez aucun avantage à avoir plusieurs référentiels, mais vous avez un coût: vous ne pouvez pas revenir à une ancienne version d'un référentiel et avoir la certitude que votre système continuera de fonctionner. En effet, votre code est étroitement couplé entre les référentiels. Étant donné que la confiance dans la capacité de revenir en arrière est l'un des principaux avantages du contrôle des sources, ce n'est pas la situation dans laquelle vous voulez être.

La solution consiste à définir votre structure de référentiel en fonction du couplage du code en son sein: si le composant de projet A partage uniquement des interfaces stables avec le composant de projet B, ils peuvent être placés dans des référentiels distincts. Sinon, ils doivent être colocalisés dans le même référentiel. Une disposition de référentiel plus granulaire reflétera une architecture système mieux factorisée.

Si chacun de vos référentiels est un projet ou une bibliothèque autonome, je dirais qu'il n'y a rien de mal à avoir à créer des branches de fonctionnalités sur chaque référentiel lors de l'ajout de nouvelles fonctionnalités transversales aux projets. En étant autonome, chacun peut être versionné indépendamment et vous pouvez déprécier les anciennes API.

Mais dans votre cas particulier, il semble que vos référentiels ne regroupent pas efficacement votre code. Si des modifications sont apportées au code dans un référentiel nécessitent des modifications dans d'autres (obsolète à part), soit votre couplage est trop serré, soit les référentiels doivent être réorganisés.

Si tous les référentiels font vraiment partie du même projet (ils ne peuvent pas être autonomes), alors vous ne devriez peut-être avoir qu'un seul référentiel. (Ou peut-être 2: le projet principal et un pour les fonctionnalités génériques / standardisées.)