¿Cómo mantener una versión demo de una aplicación?

8

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?

c# asp.net deployment maintenance OO
fuente
No ramifique el código sobre esto si puede evitarlo. No tenga una instalación separada si puede evitarlo. No ponga "demo" en la URL, hará que el producto parezca falso. Debería poder convertirlo en un parámetro de configuración. Idealmente, no tendrá si las declaraciones que verifican la configuración a través de su código, tal vez una llamada para ver si una característica es compatible, y solo el objeto de implementación que sabe por qué depende de su aplicación.
psr

Respuestas:

3

  • Mantener una rama diferente en subversión específica para el sistema de demostración

    • ¡Si! Esto ayuda de verdad. Pero ten cuidado en cómo lo haces. Lo mejor es que cuando el sistema principal evolucione, debe saber cómo reducir sus cambios lo más cerca posible.

  • 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

    • Esto podría funcionar, pero si está haciendo muchas demostraciones, perderá su buena parte de la vida en esto.
  • Modularice la aplicación (no tengo idea de cómo)
    • Esta es la mejor respuesta. Vea abajo.
  • Di: "¡Jódete! ¡No lo haré!" (LOL)
    • ¡Definitivamente no! No porque debas tener miedo. Pero un buen ingeniero no abandona los desafíos.
  • 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).
    • ¡Definitivamente no! Esto haría que su producto sea muy débil con el tiempo.

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

Dipan Mehta
fuente
Realmente me gusta tu respuesta. Para una simple ocultación y visualización de un enlace, puedo salir con una rama separada, como dijiste.
OO
No estoy de acuerdo con algunos puntos de esta respuesta. Hacer una rama diferente no es muy diferente de hacer un "producto separado", de lo que usted está (correctamente) advirtiendo al OP. Una rama a largo plazo que no se fusiona con la línea principal de desarrollo no es más que una copia que debe mantenerse por separado. Para evitar esto, existe el enfoque bien conocido del uso de alternar características , que significa "lógica condicional en la aplicación" y, a menudo, es una solución mucho mejor que abusar de las ramas SVN para esto.
Doc Brown
@DocBrown: no ha leído la pregunta y la respuesta. OP dio las cuatro opciones y la respuesta solo expone las implicaciones. La respuesta muestra esa ventaja rápida, así como las dificultades para cada uno. mientras que la función alterna definitivamente las mejores soluciones cuando hay varias variantes: la ramificación de svn es esencialmente una salida fácil para uno de esos cambios. Todo realmente depende de la visión a corto plazo frente a largo plazo de lo que son posibles estas variaciones. Y como lo veo, ¡la respuesta realmente evalúa todas las opciones y sus implicaciones de manera bastante neutral!
Dipan Mehta
Y, francamente, ¿qué tiene de malo esta respuesta que merece -1 voto?
Dipan Mehta
No hay necesidad de insultarme. Mi comentario es exactamente sobre tus implicaciones. Escribiste "Mantener una rama diferente en subversión - ¡Sí! ". Mi opinión aquí: " No , no hagas esto, este es un consejo muy malo, ya que la demostración es probablemente una característica a largo plazo". Y escribió "Use algún tipo de lógica condicional en la aplicación - ¡ Definitivamente no! ". Pero eso es bastante contrario al uso de alternar características. Si tiene problemas con el voto negativo, edite su pregunta y resuelva estas contradicciones, tal vez haya dicho las cosas de manera diferente.
Doc Brown
9

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.

CaffGeek
fuente
+1 por una respuesta simple a una solicitud bastante simple de su jefe.
dodgy_coder