Suggestion de modèle de branchement pour le même projet, plusieurs clients

Nous avons un très gros projet qui comprend plusieurs applications qui sert de base à différents clients.

Chaque client a sa propre personnalisation du produit, différentes étapes, différentes exigences et ainsi de suite, et donc chaque projet évoluera indépendamment en fonction de ses propres besoins.

Le cœur du projet est similaire (mais pas égal) dans chaque projet et l'organisation est faite de sorte qu'il existe des équipes qui traitent chaque client de manière indépendante (mais avec une communication entre eux si nécessaire). Jusqu'à présent, je n'ai pas pu trouver de schéma qui réponde à nos besoins, que ce soit en recherchant sur Internet ou en trouvant une idée géniale :)

Jusqu'à présent, nous avons travaillé pour obtenir le produit adapté à tous les besoins, avec des branches spécifiques pour les changements nécessaires, mais, bien que le produit ait une bonne architecture, cela devient lentement un gros problème. Voici les principaux problèmes auxquels nous sommes confrontés:

• Différents jalons pour chaque client: ce qui signifie que chaque équipe doit produire des versions à des moments différents sans que les autres commits n'affectent la stabilité ou leur produit.
• Exigences différentes, qui peuvent ou non affecter le cœur du système dans certains cas.
• Grandes équipes (20+ membres de l'équipe)
• Gestion des bogues dans le système: que faire si une équipe trouve un bogue dans son projet qui pourrait affecter d'autres clients?

Remarque: Nous parlons d'un projet qui a 10 + M LOC.

Remarque: Nous utilisons Team Foundation System, Visual Studio 2008 et C # (principalement).

Avez-vous des suggestions, des sources ou des idées sur la façon d'aborder la situation? Y a-t-il un modèle sur le marché qui a un problème similaire?

En fait, je dirais que vous n'avez pas besoin d'un modèle de branchement, mais plutôt d'une approche complète et complète pour faire face aux contraintes multidimensionnelles du système sans branchement. Dans la pratique, je crois que ce sera toujours un problème de maintenir plusieurs systèmes qui ont des points communs mais qui évolueront différemment dans les branches, il est donc préférable de tout transformer en un seul système qui évoluera dans son ensemble, mais se compose de différentes configurations. Cela peut sembler trop simpliste, mais il existe des recherches approfondies dans ce domaine, avec de nombreuses applications industrielles réussies.

Le nom de cette approche est Software Product Lines ou parfois Product Line Engineering . Sur la page des gammes de produits logiciels de CMU SEI :

Une gamme de produits logiciels (SPL) est un ensemble de systèmes gourmands en logiciels qui partagent un ensemble commun et géré de fonctionnalités répondant aux besoins spécifiques d'un segment de marché ou d'une mission particulière et qui sont développés à partir d'un ensemble commun d'actifs de base d'une manière prescrite .

L'idée clé est que chaque exigence, chaque étape, chaque fonctionnalité (un terme clé dans ce domaine) fait partie du système complet au plus haut niveau. Les systèmes réels déployés chez divers clients sont essentiellement une collection de fonctionnalités. Cependant, chaque fonctionnalité n'est pas seulement un composant physique intégré dans le système, elle est définie comme dépendant ou activée par d'autres fonctionnalités (de sorte qu'en choisissant une fonctionnalité, vous pouvez automatiquement inclure ses dépendances, etc.)

Au lieu de maintenir toutes ces branches, vous finissez par maintenir un système avec un ensemble de configurations spécifiques au client.

Il peut être difficile, voire impossible dans la pratique, de migrer vers une telle approche avec un très grand système, mais même alors, il sera utile d'étudier les approches utilisées en SPL afin d'évaluer quelles approches utilisées peuvent au moins être (partiellement) intégré dans votre travail.

Quelques liens utiles supplémentaires:

• Wikipédia: Ingénierie de ligne de produits
• Études de cas par CMU SEI
• Software Product Lines , un site avec beaucoup de matériel d'introduction.

Lorsque j'ai commencé mon premier emploi, j'ai travaillé sur des projets similaires (mais à plus petite échelle) et nous avons été confrontés aux mêmes problèmes. Nous avons également commencé avec des exigences générales de gestion des solutions pour tous les clients, mais cela n'a été possible qu'au même point où les exigences deviennent contradictoires. Nous avons fait ce que vous proposez et commencé une version séparée pour chaque client. Même cela a résolu le problème des exigences et de la personnalisation, cela devient un cauchemar de maintenance pour résoudre les bugs et les changements globaux.

Comme le code dans l'application n'était que similaire, la fusion des modifications d'une version client à une autre était très complexe et nécessitait de retester chaque version séparément (nous n'avions pas de tests automatiques!). Cela provoquait souvent des bogues de régression dans différentes versions. Dans votre scénario, cela peut être encore pire car une équipe résoudra le bogue dans sa version et une autre équipe devra fusionner ce changement de la version qu'elle ne comprend pas complètement (nous étions une équipe travaillant sur toutes les versions).

À moins d'avoir un noyau global partagé, vous aurez les mêmes problèmes. Avant de quitter l'entreprise, nous avons constaté que notre approche était incorrecte. Pour prendre en charge un tel scénario de développement, nous avions besoin d'un modèle de base et de données extensible partagé qui serait configurable à partir des couches d'application personnalisables supérieures. Ce noyau doit être utilisé comme base pour chaque personnalisation spécifique au client et géré par une équipe distincte. Cela inclura certaines complications de gestion, car plusieurs chefs de projet auront besoin de ressources de la même équipe, mais c'est le seul moyen de rendre l'architecture cohérente, de contrôler l'ensemble du processus et de synchroniser les versions.

Je peux être un moyen de base, mais je pense que ce à quoi vous êtes confronté avec votre cœur de système est le même problème auquel tout le monde est confronté qui utilise des composants et doit maintenir et prendre en charge différentes versions de leurs logiciels et ces différentes versions nécessitent chacune un ensemble différent des versions des composants.

Par exemple

• la version 1.0 nécessite la bibliothèque A 1.0, la bibliothèque B 2.0, la bibliothèque C 5.6
• la version 2.0 nécessite la bibliothèque A 1.0, la bibliothèque B 3.7, la bibliothèque C 5.7
• la version 3.0 nécessite la bibliothèque A 1.2, la bibliothèque B 3.7, la bibliothèque C 5.8

La façon dont nous avons résolu le problème des composants est d'avoir toutes les versions des bibliothèques dans notre système de contrôle de version (nous les construisons sur la source) et de faire en sorte que chaque projet utilise la bonne version de bibliothèque en changeant leur chemin de recherche (chemin de référence?).

Dans Delphi, cela se fait facilement via le fichier de configuration du projet (sous contrôle de source) si vous n'avez pas besoin des bibliothèques au moment de la conception, sinon c'est toujours faisable mais devient un peu plus pénible car vous devez changer l'IDE Delphi pour l'utiliser la version correcte également (les fichiers d'enregistrement (.reg) sous contrôle de version peuvent venir à la rescousse ici).

Une solution pour votre système principal pourrait être de le traiter comme une bibliothèque pour laquelle vous maintenez différentes versions. Ce qui signifie essentiellement que vous devez configurer différentes branches pour chaque version. L'application d'un client peut alors utiliser la «version» appropriée de votre système principal en référençant le dossier de branche du système principal approprié.

Là où les dépendances de votre système central ressembleraient alors à l'exemple ci-dessus, les dépendances de vos applications clientes ont alors "juste" une référence supplémentaire: la version de votre système central.

L'avantage supplémentaire avec plusieurs applications client ici est que vous pouvez choisir quand commencer à utiliser une version spécifique de votre système principal et que vous n'êtes pas encore affecté par les modifications du système principal que vous n'êtes pas encore prêt à utiliser pour une application client spécifique.