Stratégies pour la conception de référentiels de projets multiplateformes

Question

Je suis à la recherche de stratégies concernant la mise en page/la conception des référentiels dans le cadre de projets multiplateformes. Les dépendances sont généralement les suivantes :

• Le projet a un seul nom/marque
• Chaque plateforme a un code source distinct
• Le code de la plateforme partage des ressources communes
• Les documents de conception et les autres documents sont partagés entre les plateformes.

J'ai déjà essayé (en utilisant git) ce qui suit :

Solution A :

• Chaque projet de plateforme réside dans son propre répertoire
• Les engagements vont à master pour toutes les plateformes

Avantages :

• développement d'un code propre
• pas de fusion

Inconvénients :

• est un désordre, vous devez généralement préfixer tous les journaux de commit avec la plateforme
• Parfois, inverser un commit est impossible ou très difficile/méticuleux.

Solution B :

• Chaque plateforme a sa propre branche
• Lors de la libération, un rebasement est effectué sur chaque branche puis une fusion vers master + étiquette

Avantages :

• Des journaux propres :)
• Séparation propre pour le développement pogress
• Moins de conflits

Inconvénients :

• Nécessité de fusionner avec master
• Quand toutes les plates-formes sont rebasées en même temps, la fusion vers master est HELL

J'hésite à créer un référentiel par plateforme, car le partage des ressources pourrait être difficile ou nécessiterait des tâches supplémentaires, éventuellement sources d'erreurs.

Je suis impatient de connaître votre avis.

Answer 1

Il semble s'agir d'un problème de mise à l'échelle. Un référentiel contient normalement un seul projet. Plusieurs parties d'un projet peuvent partager un module d'utilité, mais pour les petits projets, l'échelle n'est pas assez grande pour envisager de séparer le module d'utilité comme une entité à part entière. Cependant, une fois que le module d'utilité devient "grand" ou si plusieurs entités indépendantes qui le partagent doivent être séparées, il doit devenir son propre module (versionné).

Mon approche serait être d'utiliser des dépôts séparés, en fonction de la quantité de code impliquée. Je ne suis pas sûr de ce que vous entendez par tâches supplémentaires, bien qu'il s'agisse d'une refonte majeure. La première chose que je ferais est de faire des ressources partagées un dépôt autonome, et d'incorporer les versions de celui-ci comme une dépendance (spécifique à la version) dans chaque construction de plate-forme. Cela découple le développement sur chaque plateforme d'une seule version de la ressource partagée. Chaque modification du projet partagé nécessite de tester chaque plateforme de toute façon, maintenant vous avez une ligne de démarcation nette. Ensuite, vous pouvez faire de chaque projet son propre dépôt, un par un.

Si vous voulez avoir une "version partagée" d'un projet sur plusieurs plateformes, vous avez besoin d'un "projet" qui est la racine du code de construction pour cela. Vous pouvez envisager d'utiliser le dépôt partagé pour ce code également, mais cela couple les versions du code partagé aux versions du projet. Ce que vous voulez probablement, si votre code a atteint ce niveau de complexité, est encore un autre dépôt juste pour le "méta-projet" qui abrite votre code de construction. À moins que vous n'ayez un groupe de projets d'une taille folle avec lequel travailler, les builds de plusieurs projets pourraient tous résider dans un seul dépôt, leur permettant de partager un code commun. Même problème à nouveau, mais à petite échelle, un seul dépôt fonctionne. Notez que tout ceci suppose un certain niveau de tests automatisés :)

Mon expérience des projets multi-modules vient de l'utilisation de perl et de java. En perl, l'utilisation de nombreux modules partagés indépendants provenant du CPAN est la norme. En java, les dépendances modulaires peuvent être gérées en utilisant Apache Ivy ou Maven. J'ai utilisé Maven dans un environnement qui avait un méta-projet de haut niveau pour la société et des projets séparés pour chaque produit (qui dépendait du méta-projet de la société). Chaque projet était libre de faire ce dont il avait besoin. Le code qui sortait d'un projet pour être partagé entre deux ou plusieurs projets devenait un projet à part entière. Un projet particulièrement important a fini par être divisé en plusieurs projets qui héritaient tous de leur propre "méta-projet". C'est pour gérer ce type de dépendance hiérarchique que Maven et Ivy ont été conçus. Nous avons utilisé Jenkins/Hudson comme serveur d'intégration qui vérifiait automatiquement les constructions inter-projets chaque nuit (en supposant que personne ne se défile pour écrire des tests...). Une fois, nous avons eu besoin de changer le site web pour toute l'entreprise. Aucun problème, nous l'avons modifié une fois dans le méta-projet de l'entreprise et il a été repris automatiquement dans la nouvelle version de chaque projet !

Answer 2

Une autre solution est envisageable :

Séparer en trois (ou plus) dépôts :

platform1 specific
platform2 specific
common for all platforms

Vous pouvez ensuite ajouter le dépôt commun dans les autres dépôts par le biais de sous-modules .

De même, Google s'est attaqué à un problème similaire dans le référentiel Android en développant un outil personnalisé : repo . Repo utilise un dépôt git personnalisé (manifest) contenant un fichier XML (manifest.xml ou default.xml, voir dans .repo/manifests) listant les dépôts Git à extraire. De cette façon, vous pourriez aussi créer trois dépôts comme ci-dessus et un autre contenant le fichier XML pour les utiliser ensemble, ou même créer des branches pour chaque plateforme dans ce manifeste git.

Bien que je doive avertir que le dépôt est très Gerrit concentré.