come gestire una libreria comune in TFS e share dll

Question

Ho 2 diverse applicazioni impostate nel controllo sorgente di tfs. Entrambi condividono una libreria comune, configurata anche nel controllo del codice sorgente.

Il processo corrente per le modifiche alla libreria comune è crearlo, copiarlo attraverso le dll in una posizione che le altre applicazioni possano utilizzare e utilizzare. Questo è manuale e non funziona bene, specialmente ora che mi sto spostando su Build di TFS CI.

layout come questo in TFS:

-TFS 
    - Web 1 
     | Main 
     | RB_1_0 
    - Web 2 
     | Main 
     | RB_1_0 
    - Shared 
     | Main 
     | RB_1_0 
     | RB_2_0 
     | RB_3_0 

Così sto cercando di cambiare questo, automatizzare esso. Ma non sono sicuro di come posso farlo. Come puoi vedere ci sono più rami, ecc. Essendo una libreria comune che stavo considerando di configurare come lavoro con i pacchetti di nuget, dove le modifiche sono trasferite al mio web 1 e/o al web 2. Non sono sicuro di quanto sia facile per impostare questo.

Sarebbe possibile rivedere la struttura di cui sopra e dare un'opinione sul modo migliore per gestire la distribuzione delle dll emesse dal comune? In un ambiente CI? Nuget è l'opzione migliore?

Answer 1

NuGet è ciò che utilizzo per questo.

modificare il processo di build per creare nuovi pacchetti per il pacchetto comune

Aggiungi un'attività da build a nuget package, e un altro che lo copia una condivisione di rete si utilizza come un repository NuGet. Ci sono alcuni progetti che girano come Tfs NuGetter che possono essere usati invece di modificare manualmente il modello di build.

Se non si desidera modificare il modello di build, è possibile utilizzare uno strumento come [tfs deployer] e scrivere uno script di distribuzione personalizzato che crea invece i pacchetti NuGet. O scrivi qualcosa che si aggancia all'evento di compilazione completo.

Abilita Ripristino pacchetti su generazione per tutte le soluzioni

questo significa che non c'è bisogno di memorizzare i pacchetti di controllo del codice sorgente, o trattare con i pacchetti non scaricare quando si arriva tardi alla soluzione.

Quando si desidera aggiornare la versione della dipendenza, aprire la soluzione e aggiornarla come qualsiasi pacchetto NuGet normale.