Utilizzo del repository NuGet privato e di Jenkins per gestire le dipendenze

Question

Utilizzo del repository NuGet privato e di Jenkins per gestire le dipendenze

#1 da (3 voti)

4

Sto sperimentando l'utilizzo di un repository NuGet privato e jenkins per gestire le dipendenze.

Diciamo che abbiamo l'exe A e le librerie B, C e D.

Exe A dipende dalla libreria B che dipende da C e D.

Alla trasmissione delle modifiche al codice in B, C o D, jenkins crea e pubblica un pacchetto NuGet separato per B, C e D nel nostro repository privato. Tutto bene.

Mi piacerebbe essere in grado di fare in modo che le modifiche apportate a C attivino un aggiornamento di nuget e la generazione di B e quindi A.

Il problema è che l'aggiornamento di nuget causa modifiche del file packages.config nel progetto dipendente. Questo cambiamento avviene nello spazio di lavoro di jenkins per quel progetto.

Questa modifica, nella mia mente, dovrebbe essere inviata al SCM. Il che farebbe sì che un jenkins si costruisca all'infinito.

A: Sto facendo bene?

B: C'è un modo per farlo funzionare?

continuous-integration dependencies dependency-management jenkins nuget

posta Kevin Pluck 27.11.2016 - 22:41

fonte

1 risposta

Leggi altre domande sui tag continuous-integration dependencies dependency-management jenkins nuget

Soluzione di database bundle in applicazione standalone Come definire e condividere uno schema JSON tra front-end e back-end di un'applicazione?

score 3 · Accepted Answer

I would like to be able to have any changes pushed to C trigger a nuget update and build of B and then A.

Non lo farei.

Quando cambi C, non ti importa di B o A, poiché non sono le tue dipendenze. In questo modo, sai per certo che indipendentemente dalle modifiche apportate a C, ogni altro progetto basato su C continuerà a funzionare.

Se, in seguito, gli sviluppatori (incluso te stesso) che lavorano su B decidono di voler beneficiare delle nuove funzionalità fornite dalla versione più recente di C, allora è loro compito aggiornare la versione della loro dipendenza. In questo modo, sanno esattamente che, ad esempio, passare dalla 4.0.13 alla 4.0.14 ha portato un dato test di integrazione a fallire.

Ci sono quattro problemi con il tuo approccio:

Non scala. Sì, potrebbe funzionare su un piccolo progetto in cui A dipende da B che dipende da C e D. Con quattro componenti, potrebbe essere utilizzabile. Ma cosa succede se hai duecento componenti e stai modificando una libreria principale su cui si basa praticamente ogni altro pezzo di software?
È contro-intuitivo. Devi conoscere le tue dipendenze, non chi dipende da te.
Rende praticamente impossibile apportare modifiche su larga scala. Immagina che invece di passare dalla 4.0.13 alla 4.0.14, ti stai spostando dalla 4.0.13 alla 5.0.0, mentre riscrivi metà delle interfacce. La prossima volta che fai un commit, alcune migliaia di test falliscono simultaneamente, e tutti gli altri sviluppatori ti fissano in attesa che tu risolvi il problema al più presto.
Introduce una distinzione inutile tra i pacchetti privati e pubblici. Pensi che gli sviluppatori di Entity Framework o Json.NET possano anche correggere il tuo codice che non è compatibile con le ultime modifiche?