Gestione delle dipendenze interne di terze parti

Question

Abbiamo molte soluzioni/progetti diversi gestiti da diversi team. La nostra soluzione deve fare riferimento a diversi progetti di proprietà di un altro team. Non vogliamo aggiungere queste dipendenze come riferimenti di progetto perché non intendiamo modificare quel codice, vogliamo solo usarlo. Inoltre abbiamo già un bel po 'di progetti nella nostra soluzione e non vogliamo aggiungere altro perché rallenterà Visual Studio. Quindi stiamo costruendo questi progetti in una soluzione separata e aggiungendoli come riferimenti di file alla nostra soluzione.

La mia domanda è: in che modo le persone gestiscono questi tipi di dipendenze? Dovrei semplicemente avere un processo automatizzato che cerchi le modifiche a quei progetti, li costruisce e controlla le DLL nel nostro controllo del codice sorgente, dopo di che le trattiamo come altre dipendenze di terze parti? C'è un modo consigliato per farlo?

Answer 1

Una soluzione, anche se potrebbe non essere necessariamente quella che si sta cercando, è quella di fare in modo che ogni sottosistema dipendente esegua un rilascio. Questa versione potrebbe essere sotto forma di installazione MSI o solo una condivisione di rete di assiemi. Quando viene apportata una modifica significativa, quel team potrebbe farti sapere, e potresti eseguire l'installazione o uno script per copiare i file.

Una volta ottenuto il rilascio, è possibile inserirli nel GAC, in questo modo non ci si deve preoccupare di copiarli nelle cartelle del progetto.

Un'altra soluzione, supponendo che si stia utilizzando un server di build o un'integrazione continua di qualche tipo, è di avere una fase di post-produzione o una fase di elaborazione dei file. Che in un dato momento, gli sviluppatori degli altri team potrebbero afferrare i nuovi file, o fare in modo che uno script o un file bat li localizzi localmente.

MODIFICA - UN'ALTRA SOLUZIONE Potrebbe essere meglio chiedere perché si dispone di queste dipendenze? Ne hai davvero bisogno localmente quando costruisci la tua parte dell'applicazione? Potresti prendere in giro le dipendenze della tua soluzione, permettendoti di scrivere codice, compilare ed eseguire test unitari? L'applicazione effettiva li collegherebbe negli ambienti DEV/Test/Prod. Mantenere la soluzione disaccoppiata e dipendente libera può essere una soluzione migliore per il singolo team. Lasciare l'integrazione e l'accoppiamento quando l'applicazione viene eseguita in un'impostazione reale.

Answer 2

(^{Non un completa risposta, ma ancora:})
Qualsiasi consegna è meglio memorizzato in un file/repository binario, al contrario di un VCS utilizzato per gestire fonti di storia.

Preferiamo la gestione di tali consegne in un repo come Nexus, e che stiamo usando maven per ottenere indietro le dipendenze di destra.
Anche se questi strumenti possono essere più orientati a Java, Nexus può memorizzare qualsiasi cosa, e Maven è lì solo per leggere lo pom.xml di ogni artefatto e calcolare le giuste dipendenze.