🕐 Tempo di lettura: 3 minuti
Negli ultimi mesi, insieme al mio team, abbiamo portato avanti una complessa migrazione del modello dati che ha coinvolto sia il database sia i vari layer del backend che lo interrogano. Un processo articolato, che ha coinvolto le fondamenta del progetto e si è svolto in parallelo all'evoluzione funzionale della piattaforma.
📌 Refactoring e disaccoppiamento – dagli oggetti di modello ai DTO
La prima sfida è stata il refactoring dello strato di repository: abbiamo riscritto le query preesistenti, condivise da diversi servizi, adottando un approccio orizzontale per interrogare in modo coerente il nuovo schema. Per i livelli superiori (service e converter) ci siamo mossi dominio per dominio con un approccio verticale, allineando gradualmente il sistema al nuovo modello. Fondamentale, in origine, è stato il disaccoppiamento tra oggetti di modello e DTO, che ha permesso di isolare le modifiche al database senza impattare il FE.
📌 Una suite di test robusta contro le regressioni
Per prevenire regressioni rispetto al vecchio modello e garantire la massima stabilità, abbiamo esteso e aggiornato la già robusta suite di test preesistente. Essa include circa 100 test di integrazione, eseguibili sia su database containerizzati con Docker che in DB locale, e oltre 500 test unitari che coprono ogni livello del progetto, raggiungendo una code coverage superiore al 90%.
📌 Branch management – organizzazione e isolamento delle evolutive
Per gestire la migrazione senza bloccare gli sviluppi, ci siamo affidati a un repository GIT a quattro livelli:
master: codice stabile, pronto per la produzionedevelop: raccoglie le modifiche da rilasciare a fine sprint e le fix urgentisprint: ramo attivo per lo sprint corrente (archiviato e ricreato ogni due settimane)feature/fix: rami dedicati a singole funzionalità, integrati insprintcon merge squash
Abbiamo creato un branch separato (migration) parallelo a develop/sprint, dove abbiamo concentrato le modifiche per la migrazione. Una volta terminati i test manuali di QA e gli ultimi affinamenti, effettueremo il merge in develop.
📊 La migrazione in numeri
Per dare un'idea della scala, il git diff --shortstat finale parla chiaro:
687 files changed, 17.508 insertions(+), 16.649 deletions(-)
In conclusione, questa migrazione non ha rappresentato solo un cambiamento tecnico, ma un vero e proprio banco di prova per le nostre strategie architetturali e di gestione del codice. Attraverso un approccio metodico, abbiamo dimostrato come sia possibile affrontare sfide complesse senza compromettere la stabilità del sistema.
Alla prossima pillola! ☕