Necesito poder demostrar nuestra aplicación de producción a clientes potenciales. La forma en que lo configuré hoy es simple. La aplicación de demostración es un duplicado exacto del sistema de producción, excepto que los datos en la base de datos están ofuscados para proteger los datos de nuestros clientes actuales. Esto funciona muy bien porque no requiere ningún cambio de aplicación.
Boss dejó caer un BOMBSHELL potencial hoy y dijo que el sistema de demostración necesita contener un enlace especial y que SOLO aparece en la demostración. Continuó explicando que en el futuro puede haber diferencias mucho mayores entre las aplicaciones de demostración y producción (por ejemplo, un área completa de funcionalidad). ¿Qué hago ahora?
Algunas cosas que he pensado hacer:
- Mantener una rama diferente en subversión específica para el sistema de demostración
- Cree un paquete de instalación que tenga los cambios para la demostración, luego revierta y cree un paquete de instalación de producción
- Modularice la aplicación (no tengo idea de cómo)
- Di: "¡Jódete! ¡No lo haré!" (LOL)
- Use algún tipo de lógica condicional en la aplicación para determinar si es una aplicación de demostración o de producción. Por ejemplo (si la URL contiene 'demo', entonces muestre hide).
Si aún no lo ha adivinado, esta es una aplicación web
De todos modos, no tengo experiencia en este escenario en cuanto a cuál es mejor o si ninguno de estos es bueno. ¿Alguien tiene una respuesta, estrategia, algo?
Respuestas:
Mantener una rama diferente en subversión específica para el sistema de demostración
Cree un paquete de instalación que tenga los cambios para la demostración, luego revierta y cree un paquete de instalación de producción
Cuando piense en un producto de demostración (a menos que esté hablando de versiones de prueba), no piense como un "producto separado" sino que piense en él como un "entorno separado". Si usted y yo instalamos el motor de word-press en nuestros sitios respectivos, tendremos el mismo producto pero datos diferentes. Debe diseñar su producto de manera que se puedan crear elementos específicos de instalación (y uso), como la forma en que uno crea diferentes fuentes de contenido. Del mismo modo, por ejemplo, si está creando una aplicación .Net o JAVA nativa, la funcionalidad sigue siendo la misma, pero de donde obtiene las imágenes (incluidas las pantallas de presentación y los botones) puede haber diferentes carpetas para mostrarlas en diferentes formas. Más adelante, la demanda incluso alterará los diseños, ¡entonces es cuando sabes que necesitas más material de plantilla!
No saltes para la modularización de una sola vez. A medida que llegue el requisito, primero comience una rama separada (línea de desarrollo) y ¡dé la demostración! (Debido a que todas las demostraciones suelen ser al día siguiente a las 10:30 a.m.). La desviación que creó ahora le dice qué modularizado debería haber estado allí para ser recogido de recursos externos. Aplíquelo y combínelo de nuevo. La próxima vez, la misma demostración sería su versión estándar (con una URL diferente).
Casi siempre si termina haciendo un "producto separado" como una demostración, ¡está invitando a problemas o dolor o ambos!
Dipan
fuente
El mejor enfoque sería modularizar para que pueda activar o desactivar elementos en cualquier aplicación.
Su demostración es una instalación de productos, con una configuración que activa diferentes cosas que la aplicación real de productos y apunta a una base de datos diferente.
fuente