Sistemas de demostración y en vivo: estrategia de control de versiones de código

Nuestra compañía tiene un producto cliente / server que queremos ofrecer al cliente para que los clientes prueben, en comparación con un server de testing con datos ficticios donde todos los usuarios tienen una count ficticia única.

Para resumir el producto, en una situación del mundo real, el server se implementaría en el entorno de alojamiento del cliente y la aplicación del cliente se entregaría a los usuarios del cliente. La aplicación cliente utiliza web services SOAP para comunicarse con el server y utilizamos mercurial para el control de versiones de bases de datos de clientes y serveres.

Mis intereses como desarrollador están preservando el mantenimiento de ambas bases de código. También creo que el comportamiento del cliente debe ser idéntico si recibe datos ficticios o en vivo. Necesito poder enviar las correcciones de errores del Live Back al sistema de demostración. Sin embargo, necesito que la versión de demostración tenga un comportamiento específico (por ejemplo, usar una count ficticia en el server que está poblada con datos ficticios).

Para tratar de conciliar estos intereses, se ha bifurcado la base de código del server con configuraciones codificadas para mostrar solo datos ficticios y para obligar a todos los inicios de session a usar la count ficticia. El server de demostración se implementa en la nube. Luego tenemos un cliente que está configurado en el instalador para que apunte a esta instancia del server en la nube, y está disponible para que los potenciales clientes lo descarguen para probarlo.

No estoy seguro de si este es el mejor enfoque. Algunos han sugerido que debería codificar la funcionalidad de demostración en el código del server en vivo, y tenerla configurable con un marcador oculto, esto evitaría la necesidad de una base de código ramificada.

El razonamiento detrás de mi enfoque es que añadir comportamiento de demostración codificado a la base de código en vivo solo para una implementación individual me parece como un olor a código. El server bifurcado nos permite continuar desarrollando la plataforma del server en la twig "en vivo" y aplicando correcciones de errores en la twig "server de demostración", y el contrato del service web y la base de código del cliente permanecen sin cambios.

Para mí, esto parece una buena separación porque, en un nivel alto, creo que el comportamiento del cliente debería ser idéntico independientemente de si está recibiendo datos en directo o ficticios del server.

Mi pregunta es si la comunidad de desarrollo más amplia ve un problema con este enfoque o tiene una mejor estrategia. ¿Es mi razonamiento válido? ¿Cuál es la mejor práctica para administrar la base de código para un sistema de demostración (con una count ficticia / datos) junto con un sistema en vivo?

Entiendo tu punto de vista pero la bifurcación te obligará a fusionar sucursales para integrar los cambios en tu demo. En mi empresa tenemos varios productos que usan la misma base de códigos, un comienzo para ahorrar time bifurcamos las bases de código, pero ahora tenemos problemas para integrar evoluciones y retroportar evoluciones en las twigs, así que usamos la diferencia de time de compilation del mismo código o time de ejecución. Entonces mi consejo (no soy la comunidad :)) es no ramificar

No hay ventajas valiosas allí, solo un esfuerzo extra de fusión. Si la diferencia entre demo y en vivo no es crítica, sugeriría mantener una única base de código.

Para personalizar el comportamiento de la demostración, sugeriría lo siguiente:

  • inclusión de código condicional: #ifdef DEMO ... #endif . Tiene una base de código única, tiene cadenas "codificadas", pero no comstackn para la versión en vivo.

  • plugins de time de ejecución, cuando tienes un poco de interfaz IDataProvider y configura demo para usar DemoDataProvider . Tiene una base de código única, código de demostración conectable, que puede excluir de la distribución en vivo.

No estoy seguro de qué tecnología está utilizando, pero en PHP tenemos el indicador de entorno (testing, desarrollo, producción). Usando el indicador de env puede tener diferentes variables de time de ejecución configuradas para reflejar el comportamiento del sistema. Podría vincular un subdominio (digamos demo.yourdomain.com) al env, configurarlo y definir cómo desea que se comporte su sistema (por ejemplo, obtenga datos de una database ficticia).

http://php.net/manual/en/reserved.variables.environment.php

Espero eso ayude.