Come strutturare molti progetti che possono essere versionati e distribuiti separatamente

Consiglierei di riflettere attentamente sulle diverse fasi del rilascio. Ad esempio, di solito quando viene creata una versione è compilato , testato , pacchetto e quindi distribuito .

Solo perché una soluzione si integra, non significa che debba essere assemblata insieme. Allo stesso modo, solo perché hai un singolo pacchetto, non significa che devi distribuire tutto nel pacchetto.

Pensare in questo modo ti darà flessibilità dove e quando ne hai bisogno.

Penso che l'opzione n. 1 o l'opzione n. 2 potrebbero funzionare. Non penso che andrei con l'opzione n. 3 perché non hai la possibilità di impacchettare e distribuire separatamente (quindi, la gestione della configurazione manterrebbe tutta la complessità).

Opzione 1:

Con questa opzione, ti dai la massima flessibilità. I vantaggi sono che i diversi team di sviluppo possono tranquillamente lavorare indipendentemente (perché il codice è fisicamente separato). Come hai suggerito, il principio DRY soffre. Tuttavia, è possibile attenuarlo incapsulando componenti comuni nei pacchetti NuGet e quindi estraendoli nelle soluzioni separate. Ciò offre anche il vantaggio di essere in procinto di eseguire la versione dei componenti comuni.

Questa opzione offre anche la possibilità di avere processi di imballaggio e di distribuzione completamente diversi. Di nuovo, puoi avere uno script o un processo standard per ciascuno, ma sono file fisici separati. Questo è vantaggioso se alcuni dei processori si svilupperanno a velocità diverse, o hanno complessità diverse, oppure sono sviluppati da gruppi di persone diversi.

Ma il lato negativo, come hai osservato, è che hai soluzioni separate e devi gestirle e mantenerle.

Opzione n. 2:

Con questa opzione, di solito si costruisce la soluzione insieme. È possibile mantenere componenti comuni nella soluzione (come progetti diversi) e farvi riferimento. Tuttavia, il controllo delle versioni dei componenti comuni tra i progetti del processore è più difficile.

Questa opzione è leggermente più difficile con i diversi team di sviluppo perché è probabile che ci sia più fusione in quanto un solo team (o dev) apporta modifiche ai componenti comuni. L'aggiunta di più progetti di processore (allo stesso tempo) causa anche problemi di unione.

Anche se costruisci insieme, puoi avere diverse routine di confezionamento per ciascuno dei processori. Quindi, puoi separare le dipendenze di ciascuno e impacchettare separatamente la distribuzione.

In breve, dipende da molti fattori sul tuo progetto. Cose come la velocità di cambiamento, la dimensione della squadra, le dipendenze del codice e la complessità di ciascun processore fanno la differenza. Non sono sicuro di aver dato una risposta chiara in un modo o nell'altro, ma spero che questo ti aiuterà nella tua decisione.

Un prodotto, un codice sorgente, dati diversi.

Non ci sono abbastanza dettagli per sapere se la mia risposta è quella giusta, ma il tuo problema è comune per i fornitori di soluzioni con più clienti che hanno requisiti leggermente diversi. Le risposte sempre su cui convergere: Just One Product.

Quando costruisci, costruisci tutto e quando esegui i test, esegui tutti i test. In questo modo una squadra non interrompe silenziosamente qualcosa per qualcun altro e tutto funziona sempre.

Quando esci, rilasci tutto. Corri cicli brevi e spedisci solo ciò che deve essere spedito, ma è tutto il tempo necessario per testare.

È possibile che venga fornito il codice per la piattaforma A che non viene utilizzato sulla piattaforma B e per i quali è necessario attivare e disattivare i dati di configurazione. A seconda delle esigenze, è possibile convergere su una soluzione che è in gran parte guidata da dati con un codice personalizzato minimo o nullo. Oppure potresti utilizzare una lingua specifica del dominio o un linguaggio di scripting per incapsulare le differenze.

Questa è un'ottima risposta a molte domande. Forse è la risposta ai tuoi.