Con l'integrazione continua in .NET, è accettabile fare riferimento a DLL di assembly che cambiano raramente?

Question

Con l'integrazione continua in .NET, è accettabile fare riferimento a DLL di assembly che cambiano raramente?

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)

7

La mia azienda sta cercando di implementare una soluzione di CI molto presto, e sono preoccupato per una cosa in particolare ... stiamo aumentando di livello, il che significa che le nostre soluzioni stanno crescendo con più progetti. Una cosa che volevo esaminare è quella di scindere i progetti raramente modificati in un progetto separato, e quindi fare in modo che altri progetti facciano semplicemente riferimento alla DLL compilata, piuttosto che includere i progetti nelle loro soluzioni.

Ad esempio ...

/ BLL / DataFramework
/ BLL / OrmFramework
/ BLL / OrmDataAdapter
/ BLL /...
/ WebUI / MyWebSite

I progetti Data e ORM dovrebbero essere modificati raramente, ma se non sono referenziati come DLL aggiungerebbero ingordigia a tutte le soluzioni.

Invece vorrei escluderli dal progetto e farli costruire in una cartella Libraries (o qualcosa di simile), in modo che:

/ BLL /...
/ Biblioteche
/ WebUI / MyWebsite

Dove gli assembly ORM e Data .DLL si trovano nella cartella Librerie.

Quindi la domanda è ...

C'è qualche ragione per cui questo non funzionerebbe con l'integrazione continua?

Posso avere una soluzione con queste classi raramente aggiornate che verranno compilate nella cartella della libreria durante l'elemento della configurazione, in primo luogo e seguite dalle altre soluzioni?

Modifica: Per essere chiari ... vogliamo mantenere questi progetti nel ciclo CI, ma non fare riferimento diretto ai loro progetti in ogni soluzione.

continuous-integration .net

posta smdrager 17.04.2012 - 22:07

fonte

4 risposte

Leggi altre domande sui tag continuous-integration .net

Molti blocchi contro singoli lavoratori non bloccanti Aiutami a capire come riprodurre video in streaming

score 2 · Answer 1

Questo funzionerebbe. Faccio qualcosa di simile in quanto trattiamo quei progetti raramente cambiati come Core DLL Framework / Architecture e esistono nella loro soluzione. Le DLL vengono pubblicate in una posizione di riferimento e le altre soluzioni fanno riferimento a queste DLL in questa posizione come richiesto.

Anche se a volte è raro trovare un bug o viene identificato un nuovo requisito, viene pianificato un cambiamento per questi progetti Framework / Architecture e vengono costruiti, testati e testati per l'integrazione rispetto a quei progetti che li utilizzano.

Una volta che i test sono stati completati, vengono rilasciati nella posizione di riferimento e altri progetti li riprendono nella loro prossima build.

Tutti i progetti non Framework / Architecture sono su un ciclo di CI e non abbiamo mai avuto problemi con questo approccio.

Un altro vantaggio di questo approccio è che si dispone di una base di codice singolo per questi progetti Framework / Architecture che facilitano il controllo dell'accesso se si dispone di un determinato IP e anche per garantire che tutte le versioni dell'applicazione che ne hanno bisogno siano in esecuzione sul stessa versione.

score 1 · Answer 2

Non c'è motivo per cui gli assembly .NET di riferimento non funzionino. Finché si includono correttamente gli assembly .NET di riferimento nel sistema di controllo del codice sorgente, il server di integrazione continua non dovrebbe avere problemi a utilizzarli per creare le soluzioni Visual Studio e i progetti sottostanti.

score 0 · Answer 3

Sì, funzionerà.

Ma vuoi davvero riempire i tuoi repository con gli assembly, che sono molto più grandi dei file sorgente? Perché non li costruisci? Finché non usi Ricostruisci o cambia alcuno dei file sorgente, sarà relativamente veloce dato che il compilatore capirà che nulla è cambiato dall'ultima build.

Se utilizzi VS10 o VS11, c'è un'ulteriore opzione per build quelle librerie nei pacchetti NuGet e distribuirle in un repository locale, consentendo il pieno controllo del controllo delle versioni. Questo è il migliore di tutti i mondi.

score 0 · Answer 4

Funzionerebbe e funzionerebbe (dove lavoro :)).

Usando server di build come Jenkins / Hudson o altri software simili, è possibile configurare build triggers per jobs (ad esempio altri build).

Puoi impostarlo in modo tale che qualsiasi modifica al progetto X attivi una build per X così come build per Y, Z, ...

Per ulteriori informazioni, puoi visitare la home page di Jenkin .