NAnt con test di integrazione DB e infine integrazione continua

Question

Ho esplorato diverse strategie per l'esecuzione di test di integrazione all'interno di alcuni script di build Nant. In genere un certo numero di script diversi sono concatenati in una build monolitica che ha obiettivi separati: stadiazione (crea una versione di stadiazione, come build), build (costruisci semplicemente le cose), integrazione (costruisci le cose ed esegui i test di integrazione). Funziona abbastanza bene, il target di compilazione impiega circa un terzo del tempo per essere eseguito come target di integrazione e non è dolorosamente lungo, quindi non mi trovo incline a eseguirlo frequentemente.

Il target di integrazione invece richiede abbastanza tempo da non volerlo fare molto spesso - idealmente poco prima che io sia pronto a fare uno schieramento. Sembra una strategia ragionevole? IOW, lo sto facendo bene?

Il piano è eventualmente quello di spostare questo progetto in integrazione continua. Sono nuovo a tutto ciò che riguarda l'integrazione continua ma penso di aver compreso il concetto di "rottura della build" quindi mi chiedo quali sono alcune buone pratiche da prendere per trarne il massimo?

Anche qualsiasi buona fonte di lettura su questo argomento sarebbe apprezzata. Grazie!

Answer 1

Sì, sei sulla strada giusta. Quello che devi fare ora è collegare il tuo nant target a un processo automatizzato. Ti consiglio di utilizzare Team City o Cruise Control come strumento CI. Dopo aver configurato il server automatizzato, puoi eseguire i test di build e unità su ogni check in (Integrazione continua). I test di integrazione potrebbero quindi essere eseguiti di notte o durante il fine settimana poiché in genere richiedono più tempo per l'esecuzione. Se i test di integrazione hanno esito positivo, è possibile disporre di un lavoro che verrà distribuito su alcuni QA o altri server.

Answer 2

Sembra che tu ci sia il 99% del percorso. Il mio consiglio è di immergermi e iniziare a farlo. Imparerai molto di più facendo il vero tuffo e facendolo piuttosto che pensare se lo stai facendo bene.

La mia azienda sta attualmente utilizzando CruiseControl e personalmente penso che sia eccezionale.

Answer 3

Vedi questo thread correlato Che cos'è un buon processo di compilazione di elementi della configurazione?

Sei sulla strada giusta. Se stai usando uno strumento CI discreto, dovresti essere in grado di impostare ogni configurazione come un progetto separato che innesca il passaggio successivo nella catena ... vale a dire una compilazione riuscita innesca test che innescano l'implementazione che innesca l'integrazione ecc.

In questo modo il tuo "break "" più vivace ferma la linea per così dire.

Usiamo CruiseControl per costruire, unit-test, configurare e distribuire, eseguire test di integrazione e copertura del codice, eseguire test di accettazione e pacchetto per il rilascio. Questo è con un sistema di circa 8 servizi web e una dozzina di database, tutti con dipendenze di configurazione e distribuzione interralizzate con tra più ambienti con configurazioni diverse (qualsiasi da caselle singole a caselle ridondanti per ciascun componente)