Raccomandazioni per l'integrazione continua per Mercurial/Kiln + MSBuild + MSTest

Question

Abbiamo il nostro codice sorgente memorizzato in depositi Kiln/Mercurial; usiamo MSBuild per costruire il nostro prodotto e abbiamo test unitari che utilizzano MSTest (Visual Studio Unit Tests).

Quali soluzioni esistono per implementare una macchina di integrazione continua (cioè macchina di produzione).

I requisiti per questo sono:

• Una build dovrebbe essere preso a calci di quando necessario (cioè il codice è cambiato nei repository ci stanno a cuore)
• Prima la costruzione attuale, l'ultima versione della fonte codice deve essere acquisita dal repository stiamo costruendo da
• la generazione deve costruire l'intero prodotto
• la generazione deve costruire tutti test unitari
• la generazione deve eseguire tutti unit test
• Un sommario di successo/fallimento deve essere inviato al termine della compilazione; questo deve includere informazioni sulla build stessa, ma anche su quali unit test falliti e quali sono riusciti.
• Il riepilogo deve contenere quali set di modifiche erano in questa build che non erano ancora nella versione precedente (!)
• Il sistema deve essere configurabile in modo che possa essere creato da più filiali (/ Archivi).

Idealmente, questo sistema dovrebbe essere eseguito su una singola casella (il nostro prodotto non è così grande) senza componenti del server.

Quali soluzioni sono attualmente disponibili? Quali sono i loro pro/contro? Dalla lista sopra, cosa si può fare e cosa non si può fare?

Grazie

Answer 1

Il nostro prodotto BuildMaster fa tutte le cose che hai elencato in base alla progettazione e non v'è un libero, un'edizione un po 'limitato (ad esempio, si può avere solo un numero limitato di fornitori di monitoraggio emissione integrarsi con esso, il cambiamento del database lo strumento di creazione di script non è incluso nella versione gratuita, ecc.) per 5 utenti o meno.

Answer 2

TeamCity, da JetBrains, i produttori di ReSharp, faranno tutto questo. Dovrai configurarlo per ciò che specificamente significa "creare il tuo prodotto", ma puoi configurare tutto ciò che hai specificato con esso.

Il software può avvisare l'utente di build non riuscite, anche per avvisare solo la persona responsabile del codice di accesso che ha interrotto la compilazione. Viene anche fornito con pratiche pagine Web che è possibile visualizzare per vedere solo le proprie modifiche, quali build hanno attraversato con successo, quali sono in sospeso e quali sono attualmente in esecuzione.

Poiché si tratta di un prodotto distribuito, è possibile farlo crescere con la propria organizzazione e il proprio prodotto. Se a un certo punto scopri che stai aspettando che la compilazione sia completata troppo, perché molte build vengono messe in coda, puoi aggiungere altri build agent. Gli agenti di compilazione sono fondamentalmente programmi client separati installati su macchine aggiuntive, che eseguono le configurazioni di build effettive.

È disponibile in due versioni, la versione professionale e quella aziendale. La versione professionale è gratuita, può contenere fino a 20 configurazioni di build, 20 utenti e 3 build agent.La versione enterprise ha utenti illimitati e crea configurazioni, e puoi anche usare la sicurezza basata su LDAP (pensa agli utenti verificati sul dominio). Ci sono anche altri bonus dalla versione enterprise. Puoi anche acquistare licenze per più agenti di costruzione se hai bisogno di più della versione iniziale 3.

Ora, se "nessun componente del server" significa che non vuoi che si comporti come un server web, stai per essere difficile trovare qualcosa che reagirà ai tuoi impegni.

Tuttavia, se si intende che non si desidera installare un sistema operativo del server, TeamCity può lavorare anche su versioni di workstation di Windows. Questo non vuol dire che non si dovrebbe prendere in considerazione la creazione di un server appropriato per questo, ma verrà eseguito su una workstation se questo è ciò che si richiede.

Answer 3

C'è sempre BuildBot che mi piace (e ho contribuito con qualche codice). È abbastanza facile da configurare ed eseguire su qualsiasi sistema operativo, e per svolgere semplici compiti come quello che dici, e notevolmente flessibile se ne hai bisogno.

Ciò che potrebbe mancare sono i log-scraper e/o i generatori di report inclusi batterie che vengono forniti da altri server CI commerciali, in particolare per i framework Enterprise-y.

Si adatta bene anche a Mozilla e Chromium, tra gli altri.

Answer 4

Quello che hai descritto sono le basi di uno strumento CI, quindi ogni strumento CI deve essere OK.
Io uso Cruise Control.NET ma è gestito da Mercurial e non è molto semplice a prima vista. Sono comunque felice con esso. Altri strumenti che mi vengono in mente sono Hudson, Team Build (da TFS) e TeamCity.

Non ho provato altri strumenti, ma si può vedere qui pro/contro:

• TeamCity vs CC.net
• Hudson vs CC.net, Link 1 e Link 2
• CC.net vs TFS

EDIT: Ho dimenticato di menzionare che Hudson e Cruise Control.net sono Open Source pro ject, puoi facilmente scrivere plugin e patch per l'installazione.

EDIT²: I bug Mercurial sembrano essere corretti nella versione 1.6 di ccnet in arrivo (modifiche commesse nel trunk questa settimana).