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

13

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?

version-control branching configuration-management merging Shiplu Mokaddim
la source
Pouvez-vous réorganiser votre fonctionnalité pour placer autant que possible dans les bibliothèques partagées (gemmes Ruby, œufs Python, haricots Java, etc.), puis assembler les parties avec l'idée de "composer" chaque élément à partir des bibliothèques?
Narfanator
Pensez à l'ajout d'un nouveau support de protocole sur le composant Serveur. Nous devons également ajouter des contrôles d'interaction appropriés (boutons, champs, etc.) pour cela dans le Web également. C'est le problème
Shiplu Mokaddim
1
Cela ressemble à une analogie avec le modèle de "pont"; vous pourriez vous en inspirer.
Narfanator
un référentiel pour les gouverner tous
Steven A. Lowe

Réponses:

8

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.

Aidan Cully
la source
2

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.)

Allan
la source