Repository

Questa sezione descrive l'organizzazione target dei repository Vinova Backbone.

L'obiettivo e costruire una piattaforma backend riusabile da piu prodotti frontend, senza copiare codice o duplicare istanze backend quando una capability puo essere condivisa.

La nuova architettura nasce in parallelo al repository rAInty corrente. Non e una migrazione automatica del vecchio repository: i servizi vengono portati e reingegnerizzati uno alla volta, partendo dal prodotto Rendicontazione.

Sezioni

• Organizzazione repository: divisione tra core, AI, infra e repository prodotto.
• Assegnazione microservizi: collocazione target dei microservizi oggi presenti nel repository rAInty.
• Package shared: gestione di @vinova/backbone-shared e possibili shared future.
• Scaffolding microservizi: template e CLI per creare nuovi servizi.
• Reti Docker: organizzazione rete per PROD e DEV.
• CI/CD e release: workflow, manifest, deploy e promotion TEST -> PROD.
• Collaboratori: permessi, branch protection e CODEOWNERS.
• Piano di partenza: ordine consigliato per avviare il nuovo backbone.

Principi

• Il backend condiviso sta in repository backbone, i frontend prodotto stanno in repository separati.
• Il repository vinova-backbone-core e solo backend: niente frontend/, Desktop/ o Mobile/.
• Il nuovo DB target e PostgreSQL. Non si porta struttura legacy MySQL nel nuovo backbone.
• datahub resta un layer interno di persistenza e non deve diventare una API frontend-facing.
• Le API utente passano dal servizio owner, in particolare da data-service quando si tratta di dati applicativi soggetti ad autorizzazione.
• Le versioni deployate devono essere governate da manifest, non da aggiornamenti manuali ripetuti di molte variabili.