Question Comment gérer plusieurs clients avec des règles commerciales légèrement différentes?


Nous avons écrit un logiciel pour un secteur de niche particulier. Ce paquet a eu beaucoup de succès, dans la mesure où nous avons recruté plusieurs clients différents du secteur, qui nous utilisent en tant que fournisseur de solutions hébergé, et beaucoup d’autres frappent à nos portes. Si nous obtenons le succès que nous visons, nous aurons littéralement des centaines de clients, chacun avec son propre site Web hébergé sur nos serveurs.

Le problème est que chaque client arrive avec ses propres personnalisations et ajustements dont il a besoin pour sa situation et ses conditions locales, souvent (mais pas toujours) en fonction de la législation ou de la bureaucratie locale ou même du comté. Donc, si probablement 90 à 95% du système est le même pour tous les clients, nous devrons créer et supporter ces petites personnalisations.

De plus, le système est encore un travail en cours. Il y a des améliorations et des corrections de bogues qui se produisent continuellement sur le système central et qui doivent être appliquées à tous les clients.

Nous écrivons du code en .NET (ASP, C #), MS-SQL 2005 est notre serveur de base de données et nous utilisons SourceGear Vault comme notre système de contrôle de source. J'ai déjà travaillé avec des branchements dans Vault et c'est génial si vous n'avez besoin que de garder 2 ou 3 branches synchronisées - mais nous envisageons de maintenir des centaines de branches, ce qui est tout simplement impensable.

Ma question est: Comment recommandez-vous de gérer tout cela?

Je pense que les réponses porteront sur l’architecture d’objets, l’architecture de serveur Web, la gestion du contrôle des sources, les équipes de développeurs, etc. J'ai quelques idées personnelles, mais je n’ai pas vraiment d’expérience entendre des personnes qui ont fait ce genre de choses avant.

Merci!


23
2017-11-02 17:02


origine


Réponses:


je recommanderais contre maintenir des branches de code séparées par client. Ceci est un cauchemar pour maintenir le code de travail contre votre noyau.

Je vous recommande de mettre en œuvre le Modèle de stratégie et couvrez vos "personnalisations client" avec des tests automatisés (par exemple, Unit & Functional) chaque fois que vous modifiez votre Core.

METTRE À JOUR:

Je recommande cela avant de recevoir trop de clients, vous devez établir un système de création et de mise à jour de chacun de leurs sites Web. Votre flux de revenus actuel va bien sûr compenser votre implication, mais vous devez avoir une idée en tête.

Par exemple, lorsque vous venez de vous inscrire sur le site X (avec un peu de chance, tout via le Web), leur site Web sera créé en XX minutes et enverra un email au client indiquant qu'il est prêt.

Vous voulez certainement configurer un Intégration continue (IC) environnement. TeamCity est un excellent outil et gratuit.

Grâce à cela, vous pourrez vérifier vos mises à jour dans un environnement intermédiaire et les appliquer à vos instances de production.

Bottom Line: Une fois que vous avez dépassé une poignée de clients, vous devez penser à automatiser vos opérations et à déployer votre déploiement sous un autre angle. application à lui-même.

METTRE À JOUR: Ce poster souligne les effets négatifs de la création de succursales par client.


20
2017-11-02 17:12



Ce n'est pas quelque chose que vous voulez résoudre avec la gestion du contrôle de code source, mais dans l'architecture de votre application.

Je proposerais une sorte de plugin comme l'architecture. Les plug-ins à utiliser pour chaque site Web deviendraient alors un problème de configuration et non un problème de contrôle des sources.

Cela vous permet d'utiliser des branches, etc. pour les choses pour lesquelles elles sont destinées: développement parallèle du code entre (ou peut-être même sur) les versions. Chaque plugin devient un projet (ou sous-projet) distinct au sein de votre système de code source. Cela vous permet également de combiner tous les plug-ins et votre application principale dans une solution de studio visuel pour vous aider avec les analyses de dépendance, etc.

Coupler les divers composants de votre application est la meilleure solution.


10
2017-11-02 17:11



Nos logiciels ont des exigences très similaires et j'ai pris quelques petites choses au fil des ans.

Tout d’abord, ces personnalisations vous coûteront à court et à long terme. Si vous en avez le contrôle, placez des freins et des contrepoids de telle sorte que les ventes et le marketing ne vendent pas trop de personnalisations.

Je suis d'accord avec les autres affiches qui disent de ne PAS utiliser le contrôle de source pour gérer cela. Il doit être intégré dans l’architecture du projet chaque fois que possible. Lorsque j'ai commencé à travailler pour mon employeur actuel, le contrôle des sources était utilisé pour cela et il est vite devenu un cauchemar.

Nous utilisons une base de données distincte pour chaque client, principalement parce que pour beaucoup de nos clients, la loi ou le client l'exigent eux-mêmes en raison de problèmes de confidentialité, etc.

Je dirais que les différences de logique métier ont probablement été la partie la moins difficile de notre expérience (votre kilométrage peut varier en fonction de la nature des personnalisations requises). Pour nous, la plupart des variations de la logique métier peuvent être décomposées en un ensemble de valeurs de configuration que nous stockons dans un fichier xml modifié lors du déploiement (si spécifique à la machine) ou stocké dans un dossier spécifique au client et conservé dans le contrôle des sources au dessous de). La logique métier obtient ces valeurs lors de l'exécution et ajuste son exécution de manière appropriée. Vous pouvez l'utiliser de concert avec divers schémas de stratégie et d'usine. Les champs de configuration peuvent contenir des noms de stratégies, etc. En outre, les tests unitaires peuvent être utilisés pour vérifier que vous n’avez pas cassé d’éléments pour d’autres clients lorsque vous apportez des modifications. Actuellement, l'ajout de la plupart des nouveaux clients au système implique simplement de mélanger / faire correspondre les valeurs de configuration appropriées (en ce qui concerne la logique métier).

La gestion du contenu du site lui-même, y compris les pages / feuilles de style / chaînes de caractères / images, que nos clients souhaitent souvent personnaliser, est un problème pour nous. L'approche actuelle que j'ai adoptée pour cela est de créer une arborescence de dossiers pour chaque client qui reflète le site principal. Cette arborescence est basée sur un dossier nommé "custom" situé dans le dossier du site principal et déployé avec le site. Le contenu placé dans l'ensemble de dossiers spécifique au client remplace ou fusionne le contenu par défaut (selon le type de fichier). Au moment de l'exécution, le fichier correct est choisi en fonction du contexte actuel (utilisateur, langue, etc.). Le site peut être conçu pour servir plusieurs clients de cette manière. L'efficacité peut également être un problème - vous pouvez utiliser la mise en cache, etc ... pour le rendre plus rapide (j'utilise un VirtualPathProvider personnalisé). Le plus gros problème que nous rencontrons est la charge de tester visuellement toutes ces pages lorsque nous devons apporter des modifications. Fondamentalement, pour être sûr à 100% que vous n'avez pas cassé quelque chose dans la configuration personnalisée d'un client lorsque vous avez changé une feuille de style, une image, etc. partagée, vous devez inspecter visuellement chaque page après toute modification significative. J'ai développé un certain «ressenti» au fil du temps quant aux changements qui peuvent être apportés facilement sans casser les choses, mais ce n'est pas du tout un système infaillible.

Dans mon cas, je n’ai pas d’autre contrôle que celui de donner mon opinion sur les personnalisations visuelles / de code qui sont vendues si bien plus que je ne l’aurais souhaité.


10
2017-11-02 19:13



Comme mentionné précédemment, le contrôle de la source ne semble pas être une bonne solution pour votre problème. Pour moi, il est préférable d'avoir une base de code unique en utilisant une architecture multi-locataires. De cette façon, vous bénéficiez de nombreux avantages en termes de gestion de votre application, de charge sur le service, d'évolutivité, etc.

Notre produit utilisant cette approche et ce que nous avons est une partie (beaucoup) des fonctionnalités de base qui sont les mêmes pour tous les clients, des modules personnalisés utilisés par un ou plusieurs clients et au cœur de la «personnalisation» est un moteur de workflow simple qui utilise des flux de travail différents pour différents clients, de sorte que chaque client bénéficie des fonctionnalités de base, de ses propres flux de travail et d’un ensemble étendu de modules spécifiques au client ou généralisés pour plusieurs clients.

Voici quelque chose pour vous initier à l'architecture multi-locataires:

Architecture de données multi-locataire

Modèles de location de base de données SaaS


2
2017-11-02 17:33



Sans plus d'informations, telles que les types de personnalisation spécifiques au client, on ne peut que deviner à quel point les modifications sont profondes ou superficielles. Quelques approches simples / standard à prendre en compte:

  • Si vous pouvez conserver une configuration centrale en spécifiant l'unicité du client au client
  • Si vous pouvez centraliser les règles métier dans une classe ou un groupe de classes
  • Si vous pouvez stocker les règles métier dans la base de données et les extraire en fonction du client
  • Si les règles métier peuvent toutes être basées sur DB / SQL (chaque client ayant sa propre base de données)

Les différences globales de codage en fonction du nom / identifiant du client sont très problématiques, le maintien de différentes bases de code par client est coûteux (pensez au temps de test / test complet requis pour les 90% qui ne changent pas) ... requis pour répondre correctement (donner quelques détails)


1
2017-11-02 19:15



Calquez l'application. L'une de ces couches contient des personnalisations et devrait pouvoir être extraite à tout moment sans affecter le reste du système. Les «déclencheurs» au niveau de l'application et de la base de données (cités parce qu'ils utilisent souvent ou non des déclencheurs de base de données) qui appellent un code spécifique au client ou sont paramétrés avec des clés client) sont très utiles.

Le noyau ne doit jamais être personnalisé, mais vous devez le mettre en couche quelque part, même si le filtrage Web est simpliste.


0
2017-11-02 17:18



Ce que nous avons, c'est une base de données de base qui a les fonctionnalités que tous les clients obtiennent. Chaque client dispose ensuite d'une base de données distincte contenant les personnalisations de ce client. Cela coûte cher en termes de maintenance. L'autre problème est que lorsque deux clients demandent une fonctionnalité similaire, cela se fait souvent différemment par les deux équipes distinctes. Il y a actuellement peu de choses à faire pour partager les personnalisations entre les clients et faire en sorte que les plus communes deviennent partie intégrante de l'application principale. Chaque client dispose de son propre portail d’application, de sorte que nous n’avons pas à nous soucier d’un changement de client affectant un autre client.

En ce moment, nous envisageons de passer à un processus utilisant un moteur de règles, mais certains craignent que la performance ne soit pas là pour le nombre de dossiers à traiter. Cependant, dans votre situation, cela pourrait être une alternative viable.


0
2017-11-02 19:23