Cómo iniciar una nueva versión principal de mi aplicación, pero aún así mantener la versión anterior 'viva'

8

Tengo dos aplicaciones, llamadas A y B. La versión actual de estas aplicaciones es 7.x (algunos clientes ejecutan 7.1, otros ejecutan 7.2, ...). Ambas aplicaciones utilizan un mismo marco común (llamémoslo C), como este:

+---+ +---+
| A | | B |
+---------+
|    C    |
+---------+

Debido a algunos nuevos clientes importantes, quiero tener la funcionalidad de A y B en una gran aplicación. La fusión de A y B en una aplicación no es posible, por lo que ahora estoy tratando de integrar la funcionalidad de A en B. Hasta ahora, bien, pero estoy empezando a encontrar algunos problemas.

En primer lugar, los clientes que solo usan la funcionalidad básica de B no están interesados en todas las nuevas funcionalidades de A que se agregan (y que causan una sobrecarga adicional para ellos). Solo quieren actualizar su versión B con soporte para nuevas versiones de Windows, ... y quizás también quieran toda la funcionalidad agradable que se agrega a C (el marco común) también.

Segundo, los clientes que actualmente utilizan la aplicación A, no quieren pasar directamente a la aplicación B, aunque la funcionalidad combinada de A + B les ayudaría a largo plazo. Para actualizaciones fáciles, quieren seguir con A, e incluso ver algunas mejoras en C.

En tercer lugar, todos los desarrollos que estoy haciendo en B podrían tener un impacto en la capa común C. Por ejemplo, Para mejorar el rendimiento de un módulo en B, tengo que refactorizar un módulo en C, pero como C también se usa en A, necesito hacer mucho más trabajo. Además, A es una aplicación más antigua y menos estructurada, y cada cambio en C podría hacer que A sea más inestable.

¿La pregunta es cómo proceder? Actualmente estoy pensando en dividir B en una versión 7.x (todavía podría hacer algunos desarrollos menores aquí y la versión 7.3, 7.4 en los próximos años si fuera necesario), y una versión 8.x (que contendría toda la nueva funcionalidad) . Para resolver el problema de la capa común, también podría dividir C en una antigua C (7.x) y una nueva C (8.x). Esto da el siguiente resultado:

+-------+ +-------+  +-------+
| A 7.x | | B 7.x |  | B 8.x |
+-----------------+  +-------+
|      C 7.x      |  | C 8.x |
+-----------------+  +-------+

La aplicación A ya no evolucionaría y se atendría a la versión 7.x de la capa C común.

Dividir C significa que todos los desarrollos en C no se verán en los antiguos A y B (que aún serían la versión 7.x), o si deben hacerse en la versión 7.x de A y B, Requieren hacer los desarrollos en ambos lanzamientos.

Una alternativa podría ser dividir B en B 7.x y B 8.x, pero esto limitaría las posibilidades de refactorización en C, y en realidad solo resuelve los dos primeros problemas.

¿Alguien tiene alguna experiencia con este tipo de cambio de versión importante? ¿Alguna otra idea?

    
pregunta Patrick 14.03.2013 - 15:17

1 respuesta

3
  

En primer lugar, los clientes que solo usan la funcionalidad básica de B no están interesados en todas las nuevas funcionalidades de A que se agregan (y que causan una sobrecarga adicional para ellos).

Por lo general, esto solo es un problema de la interfaz de usuario: lleve la funcionalidad de A a su aplicación combinada "B 8.x", pero sepárela de una forma que los clientes de B no vean a nivel de interfaz de usuario. Incorpore un interruptor a la aplicación para que pueda activar la funcionalidad A solo para "clientes A". Probablemente necesite tener otro interruptor para ocultar la funcionalidad B para los clientes A (esto también le brinda la oportunidad de venderles la funcionalidad B como un módulo separado)

  

Segundo, los clientes que actualmente utilizan la aplicación A, no quieren pasar directamente a la aplicación B, aunque la funcionalidad combinada de A + B les ayudaría a largo plazo.

Supongo que esto no será un problema si te interesan dos cosas:

  • encuentre una manera de diseñar su interfaz de usuario para la "funcionalidad A" en "B 8.x" de una manera que no sea muy diferente en comparación con A 7.x
  • ofrecer a esos clientes A la transición a B 8.x por el mismo precio que de A 7.x a A 7. (x + 1). O bien, declare "B 8.x" con las funciones B deshabilitadas como "A 7. (x + 1)" a los clientes A (cómo nombrar un seguimiento puede ser un problema de contrato, debe verificarlo).

Finalmente, si puede migrar sus clientes A a B 8.x de esta manera, resolverá automáticamente su tercer problema.

Una cosa para agregar: estoy manteniendo una aplicación que estaba en una situación muy similar hace unos 15 años ("A 7.x" era un programa MS DOS, "B 7.x" era un programa de Windows con mucho de nuevas características, y "B 8.x" contenía todas las funciones de ambos predecesores, donde las antiguas funciones "A 7.x" se integraron en B y se vendieron como un módulo separado). No se sorprenderá cuando le diga que ya no tenemos clientes de MS DOS desde hace más de 10 años, por lo que la transición no fue un problema en absoluto.

    
respondido por el Doc Brown 14.03.2013 - 15:46

Lea otras preguntas en las etiquetas