Migrazione dallo schema del database precedente, riscrittura legacy o sync su new

Naviga le tue risposte
2

Al momento stiamo progettando la nostra nuova versione di un'applicazione esistente. Questa nuova versione non riutilizzerà alcun codice esistente poiché il vecchio codice ha più di 10 anni e è strettamente accoppiato.

Con questa nuova applicazione creeremo un livello di persistenza. E poiché vogliamo aderire a un ciclo di sviluppo agile. Avremo bisogno di un modo per far affiancare sia le vecchie che le nuove applicazioni. Personalmente potrei pensare a due soluzioni per far funzionare le applicazioni sugli stessi dati, e mi piacerebbe avere il tuo input su quale sia la soluzione più praticabile. Naturalmente se conosci una soluzione completamente diversa, sentiti libera di rispondere anche a questo.

impostazione corrente

Attualmente stiamo eseguendo due MariaDB nella replica master-master. Gli ID vengono incrementati automaticamente con uno che genera gli odd e gli altri id.

nuova configurazione

Non abbiamo ancora chiarimenti su questo. Tranne che vorremmo rimuovere la generazione di chiavi primarie dal livello di persistenza e infrastruttura. Un altro desiderio è la scalabilità. Quest'ultimo preferibilmente con segregazione in lettura (se pertinente alla domanda)

1. Sync

Crea codice per sincronizzare continuamente tutti i dati tra vecchio e nuovo. Ciò significa che deve conoscere la vecchia struttura e la nuova struttura ed essere in grado di spostarlo. Il problema più grande sembra essere la latenza introdotta dalla sincronizzazione che potrebbe causare anomalie nei dati. Per ridurlo, potremmo fare in modo che uno dei sync termini il "master"

2. Implementa nuova persistenza nei vecchi

Fondamentalmente l'idea sarebbe di avere tutta la logica di persistenza nella propria base di codice. In questo modo potremmo inserirlo nella nostra vecchia applicazione e scrivere adattatori per far sì che utilizzi già il nuovo sistema. Mi piace questo approccio in quanto rafforza una fonte di verità. Problemi con questo approccio potrebbero essere che potrebbe richiedere molto più tempo per implementare gli adattatori; così come potrebbe essere problematico far sì che il codice legacy funzioni insieme alla nuova struttura. Per non parlare, dovendo dilettarsi nel codice spaghetti non testato.

Quale sarebbe il corso migliore? (Preferibilmente con argomenti oggettivi sui vantaggi rispetto all'altro metodo

posta Maarten Bicknese 18.06.2018 - 18:18
fonte

2 risposte

2

Agile preferisce il software di lavoro, ma questo non significa necessariamente un software completo. Dal punto di vista dell'ingegneria del software, vorrei limitare la quantità di tempo in cui entrambi stanno funzionando fianco a fianco.

Potresti mantenere il vecchio sistema fino a quando il nuovo sistema non sarà pronto a prendere il sopravvento e continuare regolarmente a importare / sincronizzare i dati dal vecchio al nuovo, per testare, e così sarà pronto dopo il passaggio. Quindi è possibile rimuovere o eliminare gradualmente il vecchio sistema.

Un problema con questo approccio, è la parità delle funzionalità, o quando possiamo cambiare; questo potrebbe essere utile se il sistema è progettato in modo tale da modificare solo il back-end, e le funzionalità su di esso continueranno a funzionare. Può valere la pena di refactoring del vecchio sistema per consentire questo tipo di migrazione, per ridurre la quantità di ri / lavoro necessaria.

    
risposta data 18.06.2018 - 21:30
fonte
0

Penso che la risposta riguardi i compromessi. Decidere dove investire tempo ora per risparmiare tempo più tardi.

Prima di tutto c'è qualcosa di sbagliato nell'attuale schema db? In caso contrario, è possibile creare facilmente copie o sincronizzare i dati periodicamente.

Questo è solo interno o è venduto ai clienti? Se è venduto e supportato, potrebbe essere necessario aggiornare e migrare i sistemi client. In tal caso, investire tempo in un processo di aggiornamento / migrazione ripetibile ha senso.

Nella mia mente l'obiettivo sarebbe quello di arrivare al risultato finale nel modo più rapido ed efficiente possibile. La sincronizzazione e gli aggiornamenti bidirezionali sembrano un enorme sforzo per un guadagno discutibile.

Nella mia limitata esperienza di agile, mi aspetterei molti cambiamenti incrementali. Il che significa che lo schema sarà in continua evoluzione, il che significa che anche la sincronizzazione dovrebbe evolversi costantemente.

    
risposta data 20.06.2018 - 12:41
fonte

Leggi altre domande sui tag

Come devo gestire i dati dei test nei miei test funzionali? Algoritmo per progettare un grafico di un insieme di connessioni tra i nodi