Come avviare una nuova versione principale della mia applicazione, ma mantenere comunque la vecchia versione 'viva'

8

Ho due applicazioni, chiamate A e B. La versione corrente di queste applciations è 7.x (alcuni clienti eseguono 7.1, altri eseguono 7.2, ...). Entrambe le applicazioni usano una stessa struttura comune (chiamiamola C), in questo modo:

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

A causa di alcuni nuovi clienti importanti, voglio avere le funzionalità di A e B in un'unica grande applicazione. L'unione di A e B in un'unica applicazione non è possibile, quindi ora sto cercando di integrare la funzionalità di A in B. Fin qui tutto bene, ma ho iniziato a riscontrare alcuni problemi.

Prima di tutto, i clienti che utilizzano solo la funzionalità di base di B non sono interessati a tutte le nuove funzionalità di A che viene aggiunta (e che causa un ulteriore sovraccarico per loro). Vogliono semplicemente aggiornare la loro versione B con il supporto per le nuove versioni di Windows, ... e forse anche tutte le funzionalità che sono state aggiunte a C (il framework comune).

In secondo luogo, i clienti che attualmente utilizzano l'applicazione A non vogliono spostarsi direttamente nell'applicazione B, sebbene la funzionalità combinata di A + B li possa aiutare nel lungo periodo. Per aggiornamenti facili, vogliono rimanere con A e persino vedere alcuni miglioramenti in C.

In terzo luogo, tutti gli sviluppi che sto facendo in B potrebbero avere un impatto sullo strato comune C. E.g. per migliorare le prestazioni di un modulo in B, devo rifattorizzare un modulo in C, ma poiché C è anche usato in A, ho bisogno di fare molto più lavoro. Inoltre, A è un'applicazione più vecchia e meno strutturata e ogni modifica in C potrebbe rendere A più instabile.

La domanda è come procedere? Attualmente sto pensando di dividere B in una versione 7.x (potrei ancora fare alcuni sviluppi minori qui e rilasciare 7.3, 7.4 nei prossimi anni se necessario) e una versione 8.x (che conterrà tutte le nuove funzionalità) . Per risolvere il problema del livello comune, potrei anche suddividere C in una vecchia C (7.x) e una nuova C (8.x). Questo dà il seguente risultato:

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

L'applicazione A non si evolve più e si attacca alla versione 7.x del livello comune C.

Splitting C significa che tutti gli sviluppi in C non saranno visti nei vecchi A e B (che sarebbe comunque la versione 7.x), o se devono essere eseguiti nella release 7.x di A e B, sarebbe richiede di fare gli sviluppi in entrambe le versioni.

Un'alternativa potrebbe essere quella di dividere B in B 7.xe B 8.x, ma ciò limiterebbe le possibilità di refactoring in C, e in realtà risolverà solo i primi due problemi.

Qualcuno ha esperienza con un tale tipo di cambiamento di versione? Altre idee?

    
posta Patrick 14.03.2013 - 15:17
fonte

1 risposta

3

First of all, customers that only use the base functionality of B are not interested in all the new functionality of A that is added (and which causes additional overhead for them).

In genere, si tratta solo di un problema di interfaccia utente: portare la funzionalità di A nell'applicazione combinata "B 8.x", ma separarla in modo che non venga vista dai clienti di B a livello di interfaccia utente. Costruisci un passaggio nell'applicazione in modo da poter attivare la funzionalità A solo per "A clienti". Probabilmente hai bisogno di un altro switch per nascondere la funzionalità B per i clienti A (questo ti dà anche la possibilità di vendere loro la funzionalità B come modulo separato)

Second, customers that are currently using application A, don't want to directly move to application B, although the combined functionality of A+B would help them in the long term.

Suppongo che questo non sarà un problema se ti preoccupi di due cose:

  • trova un modo per progettare l'interfaccia utente per "Una funzionalità" in "B 8.x" in un modo non troppo diverso rispetto a A 7.x
  • offre a quei clienti A la transizione a B 8.x allo stesso prezzo che va da A 7.xa A 7. (x + 1). Oppure, dichiara "B 8.x" con le funzioni B disabilitate come "A 7. (x + 1)" ai clienti A (come nominare un follow-up può essere un problema di contratto, dovresti controllare questo).

Infine, se puoi migrare i tuoi clienti A in B 8.x in questo modo, risolvi automaticamente il tuo terzo problema.

Una cosa da aggiungere: sto mantenendo un'applicazione che si trovava in una situazione molto simile circa 15 anni fa ("A 7.x" era un programma MS DOS, "B 7.x" era un programma Windows con molto di nuove funzionalità e "B 8.x" conteneva tutte le funzioni di entrambi i predecessori, in cui le vecchie funzioni "A 7.x" erano integrate in B e vendute come modulo separato). Non sarai sorpreso quando ti dirò che non abbiamo più clienti MS DOS da più di 10 anni, quindi la transizione non è stata affatto un problema.

    
risposta data 14.03.2013 - 15:46
fonte

Leggi altre domande sui tag