Di recente, abbiamo migrato quasi tutto il codice sorgente nella mia azienda in un'unica soluzione.
Perché?
Inizialmente avevamo decine di soluzioni. Alcuni progetti di una soluzione hanno riutilizzato progetti di un altro e nessuno si è preoccupato di utilizzare un gestore di pacchetti. Il giorno in cui cambi sostanzialmente un progetto che viene utilizzato quasi ovunque, ti aspetti ore e ore di lavoro perso per l'intera azienda per i prossimi giorni o settimane. La parte peggiore è che non puoi nemmeno sapere che cosa sarebbe esattamente influenzato dal cambiamento.
Unire tutto il codice in una 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 questa modifica potrebbe avere in qualsiasi punto della base di codice? Visual Studio può farlo facilmente. Per me è un successo.
Anche l'integrazione continua è ora più semplice. 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 avrebbe iniziato a piangere con una soluzione, 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 si ricompila ogni progetto, con contratti di codice, analisi del codice abilitata per impostazione predefinita, ecc., Si prevede che ci vorrà del tempo. Ma nessuno si aspetterebbe di compilare 200 progetti con una velocità pari a 10 e, a proposito, non dovresti: questo è il ruolo del server di integrazione continua. Il tempo di avvio (avvio a freddo, quindi caricamento della soluzione) è incredibilmente veloce ; forse non veloce come con 10 progetti, ma comunque molto accettabile (meno di 20 secondi su una macchina acquistata più di cinque anni fa).
Andare ancora oltre, scaricare sistematicamente progetti è una buona idea (e molto semplice quando i progetti sono organizzati in directory all'interno della soluzione). Se qualcuno lavora su qualcosa che richiede il caricamento di solo tre progetti, non è necessario caricare tutti i 200 progetti (a meno che, ovviamente, le dipendenze possano essere interessate).
Anche il controllo della versione funziona come previsto (sto usando un server SVN, se è importante). Non ho lavorato in un ambiente concomitante reale, con, diciamo, dozzine di sviluppatori che commettono spesso codice, ma immagino che questo non avrebbe troppi problemi. Fai attenzione ai casi in cui molti sviluppatori aggiungono nuovi progetti contemporaneamente: unire il file .sln non è la cosa più semplice da fare.
Conclusione
Se dovessi scegliere di nuovo la decisione:
Vorrei comunque migrare tutto in un'unica soluzione. Ciò riduce enormemente il dolore delle dipendenze rotte e questo vantaggio da solo ne vale assolutamente la pena. Avere un posto centralizzato per tutto il codice è anche una buona idea; questo rende possibile, ad esempio, cercare qualcosa in 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 'più NuGet e la capacità 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 potrebbero esserlo altre società.
Infine, investire in un SSD per ogni sviluppatore può fare una grande differenza. Ma non è necessario, e nel mio caso, la base di codice è ancora memorizzata su un normale disco rigido.