¿Cómo administrar clientes múltiples con reglas comerciales ligeramente diferentes?

Question

Hemos escrito un paquete de software para una industria de nicho particular. Este paquete ha sido bastante exitoso, en la medida en que hemos registrado varios clientes diferentes en la industria, que nos utilizan como proveedores de soluciones alojadas, y muchos otros están llamando a nuestras puertas. Si logramos el tipo de éxito que buscamos, literalmente tendremos cientos de clientes, cada uno con su propio sitio web alojado en nuestros servidores.

El problema es que cada cliente presenta sus propias pequeñas personalizaciones y modificaciones que necesita para sus propias circunstancias y condiciones locales, a menudo (pero no siempre) según el estado local o incluso la legislación o burocracia del condado. Entonces, aunque probablemente el 90-95% del sistema sea el mismo para todos los clientes, vamos a tener que crear y soportar estas pequeñas personalizaciones.

Por otra parte, el sistema todavía es un trabajo en progreso. Hay mejoras y correcciones de errores continuamente en el sistema central que deben aplicarse en todos los clientes.

Estamos escribiendo código en .NET (ASP, C#), MS-SQL 2005 es nuestro servidor de bases de datos, y estamos usando SourceGear Vault como nuestro sistema de control de origen. He trabajado anteriormente en bóveda en Vault, y es genial si solo necesitas mantener sincronizadas 2 o 3 ramas, pero estamos buscando mantener cientos de ramas, lo cual es impensable.

Mi pregunta es: ¿Cómo recomendarías que administremos todo esto?

Espero que las respuestas se dirijan a cosas como arquitectura de objetos, arquitectura de servidor web, gestión de control de fuente, equipos de desarrolladores, etc. Tengo algunas ideas propias, pero no tengo experiencia en gestionar algo como esto, y Realmente agradecería saber de personas que han hecho este tipo de cosas antes.

Gracias!

Answer 1

recomendaría contra mantenimiento de ramas de código separadas por cliente . Esto es una pesadilla para mantener el código de trabajo en contra de su núcleo.

Le recomiendo que implemente el Strategy Pattern y cubra sus "personalizaciones de cliente" con pruebas automatizadas (por ejemplo, unidad & funcional) cada vez que cambie su Core.

ACTUALIZACIÓN:

recomiendo que antes de llegar demasiados clientes, es necesario establecer un sistema de creación y actualización de cada uno de sus sitios web. El grado de implicación que obtendrá se equilibrará con su flujo de ingresos actual, por supuesto, pero debe tener un final en mente.

Por ejemplo, cuando acaba de registrarse en Customer X (con suerte todo a través de la web), su sitio web se creará en XX minutos y le enviará un correo electrónico al cliente indicando que está listo.

Definitivamente desea configurar un entorno Integración continua (CI). TeamCity es una gran herramienta, y gratis.

Con esto en su lugar, podrá verificar sus actualizaciones en un entorno intermedio y luego podrá aplicar esos parches en todas las instancias de producción.

línea de base: vez que llegue a un puñado de clientes, tiene que empezar a pensar en la automatización de sus operaciones y su implementación como otro aplicación a sí mismo.

ACTUALIZACIÓN: Este post resalta los efectos negativos de la bifurcación por cliente.

Answer 2

Esto no es algo que quiera resolver con la administración de control de fuente, sino dentro de la arquitectura de su aplicación.

Me gustaría tener algún tipo de complemento como la arquitectura. Qué complementos usar para qué sitio web se convertiría en un problema de configuración y no en un problema de control de origen.

Esto le permite utilizar ramas, etc. para las cosas para las que están destinadas: desarrollo paralelo de código entre (o tal vez incluso más) versiones. Cada complemento se convierte en un proyecto separado (o subproyecto) dentro de su sistema de código fuente. Esto también le permite combinar todos los complementos y su aplicación principal en una solución de estudio visual para ayudar con los análisis de dependencia, etc.

La mejor manera de hacerlo es acoplar holgadamente los distintos componentes en su aplicación.

Answer 3

Capa la aplicación. Una de esas capas contiene personalizaciones y debe poder retirarse en cualquier momento sin afectar el resto del sistema. Los "activadores" de nivel de aplicación y de DB (citados porque pueden o no emplear desencadenantes de DB reales) que llaman al código específico del cliente o están parametrizados con las claves del cliente) son muy útiles.

El núcleo nunca debe personalizarse, pero debe acoplarlo en algún lugar, incluso si es un filtro web simplista.

Answer 4

Como mencionamos antes, el control de fuente no parece una buena solución para su problema. Para mí suena que es mejor tener una base de código única usando una arquitectura multi-tenant. De esta manera obtiene muchos beneficios en términos de administración de su aplicación, carga en el servicio, escalabilidad, etc.

Nuestro producto utilizando este enfoque y lo que tenemos es una (gran cantidad) de funcionalidad central que es la misma para todos los clientes, módulos personalizados que utilizan uno o más clientes y en el núcleo una "personalización" es un motor de flujo de trabajo simple que utiliza diferentes flujos de trabajo para diferentes clientes, de modo que cada cliente obtiene la funcionalidad principal, su propio flujo de trabajo y algunos conjuntos extendidos de módulos que son específicos del cliente o generalizados para más de un cliente.

aquí hay algo para empezar en la arquitectura multiempresa:

Multi-Tenant Data Architecture

Answer 5

Nuestro software tiene requerimientos muy similares y que he recogido algunas cosas en los últimos años.

En primer lugar, estas personalizaciones le costarán tanto a corto como a largo plazo. Si tiene control sobre él, coloque algunos controles y equilibrios de modo que las ventas & de marketing no vendan celosamente las personalizaciones.

Estoy de acuerdo con los otros carteles que dicen NO utilizar control de código fuente para gestionar esto. Debería integrarse en la arquitectura del proyecto siempre que sea posible. Cuando comencé a trabajar para mi empleador actual, el control de fuente se usaba para esto y rápidamente se convirtió en una pesadilla.

se utiliza una base de datos independiente para cada cliente, sobre todo porque para muchos de nuestros clientes, la ley o el cliente sí lo requieren, debido a preocupaciones sobre la privacidad, etc ...

diría que las diferencias de lógica de negocios probablemente haya sido la parte menos difícil de la experiencia para nosotros (su millaje puede variar según la naturaleza de las personalizaciones requeridas). Para nosotros, la mayoría de las variaciones de la lógica empresarial se pueden dividir en un conjunto de valores de configuración que almacenamos en un archivo xml modificado al momento de la implementación (si es específico de la máquina) o almacenado en una carpeta específica del cliente y mantenido en control de fuente (explicado abajo). La lógica empresarial obtiene estos valores en tiempo de ejecución y ajusta su ejecución de forma adecuada. Puede usar esto en concierto con varios patrones de estrategia y fábrica también; los campos de configuración pueden contener nombres de estrategias, etc. Además, las pruebas unitarias se pueden usar para verificar que no haya roto las cosas para otros clientes cuando realiza cambios. Actualmente, agregar la mayoría de los nuevos clientes al sistema implica simplemente mezclar/hacer coincidir los valores de configuración apropiados (en lo que se refiere a la lógica comercial).

Más de un problema para nosotros es la gestión del contenido del sitio en sí, incluidas las páginas/hojas de estilo/cadenas de texto/imágenes, que nuestros clientes a menudo desean personalizar. El enfoque actual que he tomado para esto es crear un árbol de carpetas para cada cliente que refleje el sitio principal: este árbol está enraizado en una carpeta llamada "personalizada" que se encuentra en la carpeta del sitio principal y se implementa con el sitio. El contenido colocado en el conjunto de carpetas específico del cliente sobrescribe o se fusiona con el contenido predeterminado (según el tipo de archivo). En tiempo de ejecución, el archivo correcto se elige según el contexto actual (usuario, idioma, etc.). El sitio se puede hacer para servir a varios clientes de esta manera. La eficiencia también puede ser una preocupación: puede usar el almacenamiento en caché, etc. para hacerlo más rápido (uso un VirtualPathProvider personalizado). El mayor problema al que nos enfrentamos es la carga de probar visualmente todas estas páginas cuando necesitamos hacer cambios. Básicamente, para estar 100% seguro de que no ha roto algo en la configuración personalizada de un cliente cuando ha cambiado una hoja de estilo compartida, una imagen, etc., debería inspeccionar visualmente cada página después de cualquier cambio significativo en el diseño. A lo largo del tiempo he desarrollado cierta "sensación" sobre qué cambios se pueden realizar cómodamente sin romper las cosas, pero de todos modos no es un sistema infalible.

En mi caso, no tengo más control que ofrecer mi opinión sobre qué personalizaciones visuales/de códigos se venden, por lo que MUCHOS más de los que me gustaría han sido vendidos e implementados.

Answer 6

Sin más información, como los tipos de personalización específica del cliente, uno solo puede adivinar qué tan profundos o superficiales son los cambios. Algunos enfoques simples/estándar a considerar:

• Si puede mantener una configuración central de la especificación de la singularidad de cliente a cliente
• Si usted puede centralizar las reglas de negocio a una clase o grupo de clases
• Si puede almacenar las reglas de negocio en la base de datos y sacar basado en cliente
• Si las reglas de negocio pueden ser todos DB/SQL basada (cada cliente tiene su propia base de datos

differe codificación dura general nces basado en el nombre/id del cliente es muy problemático, mantener diferentes bases de código por cliente es costoso (piense en el tiempo completo de prueba/reevaluación requerido para el 90% que no cambia) ...Creo que se necesita más información para responder correctamente (dar algunos detalles)

Answer 7

Lo que tenemos es una base de datos central que tiene la funcionalidad que todos los clientes obtienen. Entonces cada cliente tiene una base de datos separada que contiene las personalizaciones para ese cliente. Esto es costoso en términos de mantenimiento. El otro problema es que cuando dos clientes piden una funcionalidad similar, a menudo los dos equipos independientes lo hacen de manera diferente. Actualmente, se hace poco para compartir las consultas entre clientes y hacer que los más comunes se conviertan en parte de la aplicación principal. Cada cliente tiene su propio portal de aplicaciones, por lo que no tenemos la preocupación de un cambio en un cliente que afecte a otro cliente.

En este momento estamos considerando cambiar a un proceso utilizando un motor de reglas, pero existe cierta preocupación de que el rendimiento no estará ahí para la cantidad de registros que necesitamos para poder procesar. Sin embargo, en su caso, esta podría ser una alternativa viable.

Answer 8

he utilizado algunas aplicaciones que ofrecen los siguientes personalizaciones:

1. páginas web eran configurable - podríamos arrastrar campos fuera de la vista, la posición de ellos donde queríamos con nuestro propio nombre para la etiqueta del campo.
2. Agregue nuestras propias vistas o procedimientos almacenados y utilícelos en: cuadrículas de datos (junto con un proceso de actualización) e informes. Cada cliente necesitaría su propia base de datos.
3. Cartografía personalizada de archivos de Excel para importar datos al sistema.
4. Agregue nuestros propios campos calculados.
5. Posibilidad de ejecutar scripts personalizados en formularios durante varios eventos.
6. Identifica nuestros propios campos personalizados.

Si usted clientes son empresas grandes, que está casi va a tener su propio SDK, API, etc.

Answer 9

Otro gran recurso es la serie Ayende qué, usted busca en su blog para multitenencia .