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

Hemos escrito un package de software para una industria de nicho particular. Este package 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 website alojado en nuestros serveres.

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) en function del estado local o incluso de 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.

Además, el sistema sigue siendo 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 server de bases de datos, y estamos utilizando 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 twigs, pero estamos buscando mantener cientos de twigs, lo cual es impensable.

Mi pregunta es: ¿cómo recomiendas que administremos todo esto?

Espero que las respuestas aborder cosas como architecture de objects, architecture de server web, gestión de control de fuente, equipos de desarrolladores, etc. Tengo algunas ideas propias, pero no tengo experiencia real en la gestión de algo así, y realmente apreciaría escuchar de personas que han hecho este tipo de cosas antes.

¡Gracias!

Recomendaría no mantener sucursales de código por cliente . Esto es una pesadilla para mantener el código de trabajo en contra de su núcleo.

Recomiendo que implemente el Patrón de Estrategia y cubra sus "personalizaciones de clientes" con testings automatizadas (por ejemplo, Unidad y Funcional) siempre que cambie su Núcleo.

ACTUALIZAR:

Recomiendo que antes de get demasiados clientes, debe 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 website se creará en XX minutos y le enviará un correo electrónico al cliente indicando que está listo.

Definitivamente desea configurar un entorno de continuous integration (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 sus instancias de producción.

Conclusión: una vez que haya superado a un puñado de clientes, debe comenzar a pensar en automatizar sus operaciones y su implementación como una aplicación más para sí misma.

ACTUALIZACIÓN: esta publicación destaca los efectos negativos de la bifurcación por cliente.

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

Me gustaría tener algún tipo de complemento como la architecture. Qué complementos usar para qué website se convertiría en un problema de configuration y no en un problema de control de origen.

Esto le permite usar twigs, etc. para las cosas para las que están destinadas: desarrollo paralelo de código entre (o quizás 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 libremente los diversos componentes de su aplicación.

Nuestro software tiene requisitos muy similares y he recogido algunas cosas a lo largo de los años.

En primer lugar, estas personalizaciones le costarán tanto a corto como a largo ploop. Si tiene control sobre él, coloque algunos controles y equilibrios de manera que Sales & Marketing no venda celosamente las personalizaciones.

Estoy de acuerdo con los otros carteles que dicen NO usar control de fuente para administrar esto. Debería integrarse en la architecture 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.

Usamos una database separada para cada cliente, principalmente porque para muchos de nuestros clientes, la ley o el cliente lo requieren debido a problemas de privacidad, etc.

Diría que las diferencias en la lógica de negocios probablemente hayan sido la parte less 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 set de valores de configuration que almacenamos en un file 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 de negocio obtiene estos valores en time de ejecución y ajusta su ejecución de manera apropiada. Puede usar esto en concierto con varios patrones de estrategia y fábrica también; los campos de configuration pueden contener nombres de estrategias, etc. Además, las testings 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 configuration apropiados (en lo que se refiere a la lógica comercial).

Para nosotros, un problema mayor es la gestión del contenido del sitio, incluidas las páginas / hojas de estilo / cadenas de text / imágenes, que nuestros clientes a menudo desean personalizar. El enfoque actual que he tomado para esto es crear un tree de carpetas para cada cliente que refleje el sitio principal: este tree 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 set de carpetas específico del cliente sobrescribe o se fusiona con el contenido pnetworkingeterminado (según el tipo de file). En time de ejecución, el file correcto se elige según el context 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 caching, 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 configuration personalizada de un cliente cuando ha cambiado una hoja de estilo compartida, una image, etc., debería inspeccionar visualmente cada página después de cualquier cambio significativo en el layout. A lo largo del time 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, tampoco 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.

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

Nuestro producto que utiliza este enfoque y lo que tenemos es una (gran cantidad) de funcionalidad central que es la misma para todos los clientes, modules 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 algún set extendido de modules que son específicos del cliente o generalizados para más de un cliente.

Aquí hay algo para que comiences con la architecture multi-tenancy:

Arquitectura de datos multi-inquilino

Sin más información, como los types 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 configuration central que especifique la exclusividad del cliente al cliente
  • Si puedes centralizar las reglas del negocio a una class o grupo de classs
  • Si puede almacenar las reglas comerciales en la database y extraerlas en function del cliente
  • Si las reglas de negocio pueden basarse en DB / SQL (cada cliente tiene su propia database)

En general, las diferencias de encoding difíciles basadas en el nombre / id del cliente son muy problemáticas, mantener diferentes bases de código por cliente es costoso (piense en el time completo de testing / repetición requerido para el 90% que no cambia) … Creo que hay más información requerido para responder apropiadamente (dar algunos detalles)

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

El núcleo nunca debe personalizarse, pero debe colocarlo en algún lugar, incluso si es un filter web simplist.

Lo que tenemos es una database central que tiene la funcionalidad que todos los clientes obtienen. Entonces cada cliente tiene una database 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 process que utiliza un motor de reglas, pero existe cierta preocupación de que el performance no estará presente para la cantidad de loggings que necesitamos para poder procesar. Sin embargo, en su caso, esta podría ser una alternativa viable.

He usado algunas aplicaciones que ofrecían las siguientes personalizaciones:

  1. Las páginas web eran configurables: podíamos arrastrar campos fuera de la vista, colocarlos donde queríamos con nuestro nombre para la label de campo.
  2. Agregue nuestras propias vistas o procedimientos almacenados y utilícelos en: cuadrículas de datos (junto con un process de actualización) e informes. Cada cliente necesitaría su propia database.
  3. Cartografía personalizada de files de Excel para importar datos al sistema.
  4. Agregue nuestros propios campos calculados.
  5. Posibilidad de ejecutar scripts personalizados en formularios durante varios events.
  6. Identifica nuestros propios campos personalizados

Si sus clientes son compañías más grandes, casi necesitará su propio SDK, API, etc.

Otro gran recurso es la serie que Ayende hizo, usted busca en su blog multiempresa.

Intereting Posts