Qual è il modo migliore per configurare un server di test di integrazione?

Question

Configurando un server di integrazione, ho dei dubbi sull'approccio migliore riguardo all'utilizzo di più attività per completare la build.È il modo migliore per sistemare tutto in un unico grande lavoro o crearne di piccoli dipendenti?

Answer 1

Sicuramente vuoi suddividere i compiti.Ecco un bell'esempio di configurazione di CruiseControl.NET che ha obiettivi (attività) diversi per ogni passaggio.Utilizza anche un file common.build che può essere condiviso tra progetti con poca personalizzazione.

http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk

Answer 2

Utilizzo TeamCity con uno script di build nant.TeamCity semplifica la configurazione della parte del server CI e lo script di compilazione nant semplifica l'esecuzione di una serie di attività per quanto riguarda la generazione di report.

Ecco un articolo che ho scritto sull'utilizzo della CI con CruiseControl.NET, ha uno script di build nant nei commenti che può essere riutilizzato in tutti i progetti:

Integrazione continua con CruiseControl

Answer 3

L'approccio che preferisco è la seguente configurazione (supponendo effettivamente che tu sia in un progetto .NET):

• CruiseControl.NET.
• Attività NANT per ogni singolo passaggio.Nant.Contrib per modelli CC alternativi.
• NUnit per eseguire test unitari.
• NCover per eseguire la copertura del codice.
• FXCop per report di analisi statiche.
• Sovversione per il controllo del codice sorgente.
• CCTray o simili su tutti i dispositivi di sviluppo per ricevere notifiche di build, errori, ecc.

In molti progetti scopri che ci sono diversi livelli di test e attività che hanno luogo quando qualcuno effettua un check-in.A volte questi possono aumentare nel tempo fino al punto in cui può passare molto tempo dopo una build prima che uno sviluppatore possa vedere se ha interrotto la build con un check-in.

Quello che faccio in questi casi è creare tre build (o forse due):

• Una build CI viene attivata dal check-in ed esegue un SVN Get, Build pulito ed esegue test leggeri.Idealmente puoi mantenerlo fino a pochi minuti o meno.
• Una build più completa che potrebbe essere oraria (se cambia) che fa lo stesso dell'IC ma esegue test più completi e dispendiosi in termini di tempo.
• Una build notturna che fa tutto ed esegue anche la copertura del codice e l'analisi statica degli assembly ed esegue qualsiasi passaggio di distribuzione per creare pacchetti MSI giornalieri ecc.

L’aspetto fondamentale di qualsiasi sistema CI è che deve essere organico e costantemente modificato.Esistono alcune ottime estensioni per CruiseControl.NET che registrano e tracciano i tempi di creazione ecc. Per i passaggi e ti consentono di eseguire analisi storiche e quindi di modificare continuamente le build per mantenerle scattanti.È qualcosa che i manager trovano difficile da accettare: una build box probabilmente ti terrà occupato per un quinto del tuo tempo di lavoro solo per impedirgli di fermarsi.

Answer 4

Noi usiamo buildbot, con la build suddivisa in passaggi discreti.È necessario trovare un equilibrio tra il fatto che le fasi di costruzione siano suddivise con sufficiente granularità e l'essere un'unità completa.

Ad esempio, nella mia posizione attuale, costruiamo le parti secondarie per ciascuna delle nostre piattaforme (Mac, Linux, Windows) sulle rispettive piattaforme.Abbiamo quindi un unico passaggio (con alcuni passaggi secondari) che li compila nella versione finale che finirà nelle distribuzioni finali.

Se qualcosa va storto in uno di questi passaggi è abbastanza facile da diagnosticare.

Il mio consiglio è di scrivere i passaggi su una lavagna nel modo più vago possibile e poi basare i passaggi su quelli.Nel mio caso sarebbe:

1. Costruisci pezzi di plugin
   1. Compila per Mac
   2. Compila per PC
   3. Compilare per Linux
2. Crea i plugin finali
3. Esegui test del plugin
4. Costruisci un IDE intermedio (dobbiamo avviare la creazione)
5. Costruisci l'IDE finale
6. Esegui test IDE

Answer 5

Dimezzerei sicuramente i lavori.È probabile che apporterai modifiche alle build e sarà più semplice rintracciare i problemi se hai attività più piccole invece di cercare in una build monolitica.

Dovresti comunque essere in grado di creare un grande lavoro dai pezzi più piccoli.

Answer 6

Buongiorno,

Dato che parli di test di integrazione, il mio grande (ovvio) consiglio sarebbe quello di rendere il server di test costruito e configurato il più vicino possibile all'ambiente di distribuzione.

</thebloodyobvious> (-:

Saluti, Rob

Answer 7

Suddividi le tue attività in obiettivi/operazioni distinti, quindi utilizza uno script di livello superiore per collegarli tutti insieme in modo appropriato.

Ciò rende il tuo processo di creazione più facile da comprendere per altre persone (documenti mentre procedi in modo che chiunque nel tuo team possa prenderlo, giusto?), oltre ad aumentare il potenziale di riutilizzo.È probabile che non riutilizzerai gli script di alto livello (anche se questo potrebbe essere possibile se hai progetti simili), ma puoi sicuramente riutilizzare (anche se si tratta di copia/incolla) le operazioni discrete piuttosto facilmente.

Considera l'esempio di come ottenere la fonte più recente dal tuo repository.Ti consigliamo di raggruppare le attività/operazioni per recuperare il codice con alcune istruzioni di registrazione e fare riferimento alle informazioni sull'account appropriate.Questo è il genere di cose che è molto facile da riutilizzare da un progetto all'altro.

Per l'ambiente del mio team, utilizziamo NAnt poiché fornisce un ambiente di scripting comune tra le macchine di sviluppo (dove scriviamo/debugghiamo degli script) e il server CI (poiché eseguiamo semplicemente gli stessi script in un ambiente pulito).Usiamo Jenkins per gestire le nostre build, ma fondamentalmente ogni progetto richiama semplicemente gli stessi script NAnt e quindi manipoliamo i risultati (ad esempio, archiviamo l'output della build, contrassegniamo i test falliti, ecc.).