Recentemente, abbiamo migrato quasi tutto il codice sorgente della mia azienda in un'unica soluzione.
Perché?
Originariamente avevamo decine di soluzioni. Alcuni progetti di una soluzione hanno riutilizzato progetti da un altro e a nessuno importava l'utilizzo di un gestore di pacchetti. Il giorno in cui cambi sostanzialmente un progetto che viene utilizzato quasi ovunque, ti aspettano ore e ore di lavoro perso per l'intera azienda per i prossimi giorni o settimane. La parte peggiore è che non puoi nemmeno sapere quali sarebbero influenzati dal cambiamento.
L'unione di tutto il codice in un'unica soluzione era un'alternativa. Funziona bene per il momento, e le dipendenze sono ora facili da seguire. Vuoi modificare un metodo ma anche tenere traccia delle ripercussioni che questo cambiamento potrebbe avere in qualsiasi punto della base di codice? Visual Studio può farlo con facilità. Per me, è un successo.
L'integrazione continua ora è più facile. Una soluzione da compilare e distribuire. Quasi nulla da configurare.
È scalabile?
Per quanto riguarda le prestazioni, sono stato molto sorpreso da Visual Studio . Ho pensato che inizierà a piangere con una soluzione con, diciamo, 50 progetti. Oggi ci sono più di 200 progetti; Visual Studio sembrava essere abbastanza scalabile per gestirli come se ce ne fossero solo 20. Sì, ci sono cose che richiedono tempo. Se ricompilate ogni progetto, con i contratti di codice, l'analisi del codice abilitata di default ecc., Aspettatevi che ci vorrà un po 'di tempo. Ma nessuno si aspetterebbe di compilare 200 progetti con una velocità di 10 e, a proposito, non si dovrebbe: questo è il ruolo del server di integrazione continua. Il tempo di avvio (avvio a freddo, quindi caricamento della soluzione) è molto veloce ; forse non così veloce come con 10 progetti, ma ancora molto accettabile (meno di 20 secondi su una macchina acquistata più di cinque anni fa).
Per andare ancora oltre, scaricare sistematicamente i progetti è una buona idea (e davvero facile quando i progetti sono organizzati nelle directory all'interno della soluzione). Se qualcuno lavora su qualcosa che richiede solo tre progetti da caricare, non è necessario caricare tutti i 200 progetti (a meno che, ovviamente, le dipendenze possano essere influenzate).
Il controllo della versione funziona come previsto pure (sto usando un server SVN, se è importante). Non ho lavorato in un reale ambiente concorrente, con, diciamo, dozzine di sviluppatori che commettono frequentemente codice, ma immagino che questo non avrebbe troppi problemi. Fai attenzione ai casi in cui molti sviluppatori aggiungono nuovi progetti allo stesso tempo: unire il file .sln non è la cosa più facile da fare.
Conclusione
Se dovessi prendere nuovamente la decisione:
-
Continuerò a migrare tutto in un'unica soluzione. Questo riduce enormemente il dolore delle dipendenze spezzate, e solo questo beneficio ne vale la pena. Avere un posto centralizzato per tutto il codice è anche una buona idea; ciò rende possibile, ad esempio, cercare qualcosa all'interno di Visual Studio. Posso anche lavorare su due progetti debolmente correlati e avere ancora una sola finestra di Visual Studio aperta.
-
Vorrei anche studiare un po 'di più NuGet e la possibilità di ospitare un server NuGet privato. La gestione delle dipendenze tramite NuGet può risolvere alcuni dei problemi quando non si desidera unire alcuni progetti nella soluzione comune. Personalmente, non ho avuto casi del genere, ma immagino che altre aziende potrebbero avere.
-
Infine, investire in un SSD per ogni sviluppatore può fare una grande differenza. Ma non è necessario, e nel mio caso, il codice base è ancora memorizzato su un normale disco rigido.