Nel nostro lavoro, abbiamo diverse applicazioni .net che condividono molte funzionalità di base. Abbiamo creato queste applicazioni usando un'architettura n-tier pulita, ma abbiamo colto quel momento in cui ci rendiamo conto che abbiamo implementato nuovamente le stesse funzioni diverse volte. Ovviamente questo viola DRY e vorremmo correggerlo. Stiamo già utilizzando Nuget con successo per un comune codice di colla (cablaggio IoC, registrazione, impostazioni), ma vorremmo anche condividere i nostri dati e livelli aziendali tra tutte le nostre applicazioni. L'idea è che l'interfaccia utente gestirà solo le parti del livello aziendale di cui ha effettivamente bisogno.
Questo sembra inizialmente un problema diretto, ma lo sviluppo in corso potrebbe fornire alcune insidie e non siamo sicuri di come procedere. Diciamo che facciamo il nostro One Business Layer per dominarli tutti. Per brevità, la chiamerò "Fondazione". Effettuiamo il porting delle nostre applicazioni per utilizzare la Foundation e tutto procede alla grande. La Fondazione è distribuita per illuminare i livelli dell'interfaccia utente tramite nuget e stiamo bene. Ma poi iniziamo ad aggiungere funzionalità alle nostre applicazioni e ci troviamo in difficoltà.
Diciamo che stiamo lavorando al Progetto A e aggiungiamo una nuova funzionalità che richiede modifiche a Foundation. Apportiamo le modifiche alla fondazione (Foundation-A) e le inviamo al feed nuget come pacchetto instabile. Il progetto A ottiene l'ultimo pacchetto nuget e tutto va bene. Nel frattempo, un altro sviluppatore sta lavorando al Progetto B. Ottiene l'ultima Fondazione dal controllo del codice sorgente, ma la prende da un ramo stabile, in modo che non vi siano modifiche al Progetto A. Apporta modifiche e crea Foundation-B. E va tutto bene. Ma poi scopriamo quella funzionalità di implementazione di Foundation-A e Foundation-B che potrebbe effettivamente condividere il codice, quindi li combiniamo. Nel frattempo Foundation-C sta fluttuando là fuori con i suoi cambiamenti. Alla fine, Foundation-B è pronto per la produzione, quindi lo spingiamo fuori. Ma poi dobbiamo aggiornare la produzione A, B,
Sembra che potrebbe funzionare, ma siamo preoccupati di lavorare con schemi di database diversi e di mantenere tutto sincronizzato tra i vari rami del repository Foundation e i repository Project A, B e C. Sembra che probabilmente ci vorrà molto lavoro manuale, il che apre la possibilità di errori. Vorrei che il più automatizzato possibile.
Ecco lo stack che stiamo usando: C #, TFS con integrazione continua, Nuget. Le nostre applicazioni sono tutti i vari tipi di applicazioni ASP.NET. Siamo disposti a esaminare diversi SCM se ciò renderà le cose più facili.
Sto cercando modi per mantenere Nuget sano con i nostri diversi rami del codice sorgente. Non vogliamo spingere accidentalmente il codice di sviluppo nella produzione perché facciamo riferimento al pacchetto Nuget sbagliato.