Très soigneusement
L'embranchement est une option mais je trouve que c'est un peu lourd. En outre, cela facilite les modifications en profondeur, ce qui peut conduire à une correction complète de votre application si elle n'est pas contrôlée. Dans l’idéal, vous souhaitez développer autant que possible les personnalisations afin de conserver votre base de code principale aussi générique que possible.
Voici comment je le ferais bien que je ne sache pas si cela est applicable à votre base de code sans modifications et reformulations lourdes. J'avais un projet similaire où les fonctionnalités de base étaient les mêmes mais chaque client avait besoin d'un ensemble de fonctionnalités très spécifiques. J'ai créé un ensemble de modules et de conteneurs que j'assemble ensuite via la configuration (à la IoC).
Ensuite, pour chaque client, j'ai créé un projet qui contient essentiellement les configurations et le script de génération permettant de créer une installation entièrement configurée pour leur site. Parfois, j'y place également des composants personnalisés pour ce client. Mais ceci est rare et j'essaie, chaque fois que cela est possible, de le rendre sous une forme plus générique et de le mettre de côté afin que d'autres projets puissent l'utiliser.
Le résultat final est que j'ai eu le niveau de personnalisation dont j'avais besoin, j'ai eu des scripts d'installation personnalisés de sorte que lorsque je suis sur le site client, je ne ressemble pas à tweking tout le temps sur le système et, comme bonus supplémentaire, je reçois pour pouvoir créer des tests de régression accrochés directement à la construction. Ainsi, chaque fois que je reçois un bogue spécifique à un client, je peux rédiger un test qui assurera le système pendant son déploiement et pourra donc effectuer la TDD même à ce niveau.
donc en bref:
- Système fortement modulaire avec une structure de projet plate.
- Créer un projet pour chaque profil de configuration (client, bien que plusieurs puissent partager un profil)
- Assemblez les ensembles de fonctionnalités requis en tant que produit différent et traitez-le comme tel.
Si cela est fait correctement, votre assemblage de produit devrait contenir presque tous les fichiers de configuration.
Après avoir utilisé cela pendant un certain temps, j'ai fini par créer des méta-packages qui assemblent les systèmes les plus utilisés ou essentiels en tant qu'unité centrale et utilisent ce méta-package pour les assemblages client. Après quelques années, je me suis retrouvé avec une grande boîte à outils que je pouvais assembler très rapidement pour créer des solutions client. J'examine actuellement Spring Roo et vois si je ne peux pas pousser l'idée un peu plus loin en espérant pouvoir un jour créer un premier brouillon du système avec le client lors de notre première interview ... Je suppose que vous pourriez l'appeler User Driven Développement ;-).
J'espère que cela a aidé
#ifdef
marche pour vous?