Come e perché devo configurare una macchina per build C #? [chiuso]

Sto lavorando con un piccolo team di sviluppo (4 persone) su un progetto C #. Ho proposto di installare una macchina da costruzione che eseguirà build e test notturni del progetto, perché capisco che questa è una buona cosa. Il problema è che qui non abbiamo un sacco di budget, quindi devo giustificare la spesa per i poteri che sono. Quindi voglio sapere:

Aggiornamento: Jenkins è la versione più aggiornata di Hudson. Tutti dovrebbero usare Jenkins ora. Aggiornerò i collegamenti di conseguenza.

Hudson è gratuito ed estremamente facile da configurare e verrà eseguito facilmente su una macchina virtuale.

In parte da un mio vecchio post:

Lo usiamo per

• Distribuire i servizi di Windows
• Distribuire servizi Web
• Esegui test MST e visualizza tutte le informazioni di tutti i test junit
• Tieni traccia dei compiti bassi, medi e alti
• avvisi ed errori del trendgraph

Ecco alcune delle cose .net integrate supportate da Hudson

• MSBuild
• NAnt
• MSTest
• Nunit
• Team Foundation Server
• FxCop
• StyleCop
• avvisi del compilatore
• attività di codice

Inoltre, dio non voglia che tu stia usando la fonte visiva sicura, supporta anche quella . Ti consiglierei di dare un'occhiata all'articolo di Redsolo sulla costruzione di progetti .net usando Hudson

Le tue domande

• D : Che tipo di strumenti / licenze avrò bisogno? Al momento, utilizziamo Visual Studio e Smart Assembly per creare e Perforce per il controllo del codice sorgente. Avrò bisogno di qualcos'altro o esiste un equivalente di un lavoro cron per l'esecuzione di script automatici?

• A: Ho appena installato Visual Studio su una nuova copia di una VM che esegue una nuova installazione con patch di un sistema operativo Windows Server. Quindi avresti bisogno delle licenze per gestirlo. Hudson si installerà come servizio di Windows e verrà eseguito sulla porta 8080 e configurerai la frequenza con cui desideri che esegua la scansione del tuo repository di codice per il codice aggiornato, oppure puoi dirlo a compilare in un determinato momento. Tutto configurabile tramite il browser.

• Q: Cosa, esattamente, mi porterà, oltre all'indicazione di una build rotta? Devo impostare progetti di test in questa soluzione (file sln) che verranno eseguiti da questi script, in modo da poter testare determinate funzioni? Al momento abbiamo due di questi test, perché non abbiamo avuto il tempo (o francamente, l'esperienza) di fare buoni test unitari.

  A: Riceverai un'email la prima volta che una compilazione fallisce o diventa instabile. Una build è instabile se un test unitario ha esito negativo o può essere contrassegnato come instabile tramite un numero qualsiasi di criteri impostati. Quando un test unitario o una build falliscono, verrai inviato via email e ti dirà dove, perché e come fallito. Con la mia configurazione, otteniamo:

  • elenco di tutti i commit dall'ultima build funzionante
  • impegnare le note di tali commit
  • elenco di file modificati nelle commit
  • output della console dalla build stessa, che mostra l'errore o il fallimento del test

• D: Che tipo di hardware avrò bisogno per questo?

  A: Sarà sufficiente una VM

• D: Una volta che una build è stata completata e testata, è pratica comune metterla su un sito ftp o avere un altro modo per l'accesso interno? L'idea è che questa macchina crea la build, e noi tutti ci proviamo, ma possiamo fare build di debug se dobbiamo.

  A: Hudson può fare tutto quello che vuoi, incluso l'identificazione tramite l'hash md5, caricarlo, copiarlo, archiviarlo, ecc. Lo fa automaticamente e ti fornisce una lunga storia di manufatti di costruzione.

• D: Con che frequenza dovremmo creare questo tipo di build?

  A: Abbiamo il nostro sondaggio SVN ogni ora, cercando modifiche al codice, quindi eseguendo una build. Nightly è ok, ma IMO un po 'inutile dal momento che quello su cui hai lavorato ieri non ti verrà in mente la mattina quando entri.

• D: Come viene gestito lo spazio? Se realizziamo build notturne, dovremmo mantenere tutte le build precedenti o iniziare a abbandonarle dopo circa una settimana?

  A: Dipende da te, dopo così tanto tempo che sposto i nostri manufatti di build nella memoria a lungo termine o li elimino, ma tutti i dati che sono memorizzati in file di testo / file xml che tengo in giro, questo mi consente di memorizzare il log delle modifiche, i grafici di tendenza, ecc. sul server con poco spazio consumato. Inoltre puoi impostare Hudson in modo che mantenga solo artefatti da un numero finale di build

• D: C'è qualcos'altro che non vedo qui?

  A: No, vai subito a prendere Hudson, non rimarrai deluso!

Abbiamo avuto grande fortuna con la seguente combinazione:

1. Visual Studio (in particolare, utilizzando lo strumento da riga di comando MSBuild.exe e passandogli i nostri file di soluzione. Rimuove la necessità di script msbuild)
2. NAnt (come la libreria di sintassi / task XML migliore di MSBuild. Ha anche opzioni per le operazioni di controllo src P4)
3. CruiseControl.net - dashboard web integrato per il monitoraggio / avvio di build.

CCNet ha incorporato notifiche per inviare e-mail in caso di esito positivo / negativo della compilazione

Sulla giustificazione: questo toglie il carico agli sviluppatori che fanno build manuali e fa molto per eliminare l'errore umano dall'equazione. È molto difficile quantificare questo effetto, ma una volta che lo fai non tornerai più indietro. Avere un processo ripetibile per compilare e rilasciare software è fondamentale. Sono sicuro che sei stato un luogo in cui hanno compilato il software a mano ed è uscito allo stato brado, solo per far dire al tuo build build "Spiacenti, devo aver dimenticato di includere quella nuova DLL!"

Sull'hardware: il più potente possibile. Più potenza / memoria = tempi di costruzione più rapidi. Se te lo puoi permettere, non ti pentirai mai di avere una macchina di costruzione di alto livello, non importa quanto sia piccolo il gruppo.

Sullo spazio: aiuta ad avere molto spazio sul disco rigido. Puoi creare i tuoi script NAnt per eliminare i file intermedi ogni volta che inizia una compilazione, quindi il vero problema è mantenere la cronologia dei registri e i vecchi programmi di installazione delle applicazioni. Abbiamo software che monitora lo spazio su disco e invia avvisi. Quindi puliamo manualmente l'unità. Di solito deve essere fatto ogni 3-4 mesi.

Sulle notifiche di compilazione: questo è integrato in CCNet, ma se hai intenzione di aggiungere test automatici come passaggio aggiuntivo, inseriscilo nel progetto fin dall'inizio. È estremamente difficile eseguire il back test dei test una volta che un progetto diventa grande. Ci sono tonnellate di informazioni sui framework di test là fuori (probabilmente una tonnellata di informazioni anche su SO), quindi mi dilungherò sulla denominazione di strumenti specifici.

Nel mio precedente posto di lavoro abbiamo usato TeamCity . È molto facile e potente da usare. Può essere utilizzato gratuitamente con alcune restrizioni. C'è anche un tutorial su Dime Cast . Il motivo per cui non abbiamo usato CruiseControl.NET è che avevamo molti piccoli progetti ed è abbastanza doloroso configurarli tutti in CC.NET. Consiglio vivamente TeamCity. Riassumendo se sei verso l'open source, CC.NET è il nonno con una curva di apprendimento leggermente più alta. Se il tuo budget ti consente di andare sicuramente con TeamCity o controlla la versione gratuita.

Come? Dai un'occhiata al blog di Carel Lotz .

Perché? Ci sono diverse ragioni a cui posso pensare:

• Una build funzionante, se correttamente implementata, significa che tutti i tuoi sviluppatori possono costruire sulla propria macchina quando la build è verde
• Una build funzionante, se correttamente implementata, significa che sei pronto per la distribuzione in qualsiasi momento
• Una build funzionante, se correttamente implementata, significa che qualunque cosa rilasci abbia fatto un viaggio nel tuo sistema di controllo del codice sorgente.
• Una build funzionante, se correttamente implementata, significa che ti integri presto e spesso, riducendo il rischio di integrazione.

L'articolo di Martin Fowler sull'integrazione continua rimane il testo definitivo. Date un'occhiata a questo!

L'argomento principale a favore è che ridurrà i costi del tuo processo di sviluppo, avvisandoti il ​​prima possibile di avere una build rotta o fallire i test.

Il problema dell'integrazione del lavoro di più sviluppatori è il principale pericolo di crescita di una squadra. Più grande è il team, più difficile sarà coordinare il proprio lavoro e impedirgli di fare confusione con le modifiche reciproche. L'unica buona soluzione è dire loro di "integrarsi presto e spesso", controllando piccole unità di lavoro (a volte chiamate "storie") man mano che vengono completate.

Dovresti fare ricostruire la macchina di costruzione OGNI volta qualche check in, durante il giorno. Con Cruise Control, puoi ottenere un'icona sulla barra delle attività che diventa rossa (e persino parla con te!) Quando la build è interrotta.

Dovresti quindi eseguire una build pulita notturna completa in cui viene etichettata la versione di origine (dato un numero di build univoco) che puoi scegliere di pubblicare per le parti interessate (product manager, addetti al QA). Questo è così che quando viene segnalato un bug, è contro un numero di build noto (che è estremamente importante).

Idealmente, dovresti avere un sito interno in cui le build possono essere scaricate e un pulsante su cui puoi fare clic per pubblicare la build notturna precedente.

Sto solo cercando di costruire un po 'su quello che ha detto mjmarsh, dal momento che ha gettato una grande base ...

• Visual Studio. MSBuild funziona bene.
• NAnt .
• NantContrib . Ciò fornirà attività aggiuntive come le operazioni di Perforce.
• CruiseControl.net . Questo è di nuovo fondamentalmente il tuo "pannello di controllo".

Tutto quanto sopra (salvo per VS) è open source, quindi non stai guardando alcuna licenza aggiuntiva.

Come detto da Earwicker, costruisci presto, costruisci spesso. Sapere qualcosa si è rotto e puoi produrre un deliverable è utile per catturare cose presto.

NAnt include anche attività per nunit / nunit2 , in modo da poter effettivamente automatizzare i test delle unità. È quindi possibile applicare fogli di stile ai risultati e, con l'aiuto del framework fornito da CruiseControl.net, ottenere risultati di test di unità stampabili e leggibili per ogni build.

Lo stesso vale per l' attività ndoc . Fai produrre e rendere disponibile la tua documentazione per ogni build.

È anche possibile utilizzare l' attività exec per eseguire altri comandi, ad esempio producendo un Windows Installer utilizzando InstallShield.

L'idea è di automatizzare la costruzione il più possibile, perché gli esseri umani commettono errori. Il tempo trascorso davanti è tempo risparmiato lungo la strada. Le persone non devono fare da babysitter alla build attraverso il processo di compilazione. Identifica tutti i passaggi della tua build, crea script NAnt per ogni attività e crea gli script NAnt uno per uno fino a quando non avrai completamente automatizzato l'intero processo di compilazione. Inoltre mette tutte le tue build in un unico posto, il che è buono per scopi di confronto. Qualcosa di rotto nella Build 426 che ha funzionato bene nella Build 380? Bene, ci sono i prodotti pronti per il test: prendili e testali via.

• Nessuna licenza necessaria. CruiseControl.net è disponibile gratuitamente e per costruire è necessario solo .NET sdk.
• Un server di compilazione, anche senza test unitari automatizzati, fornisce comunque un ambiente controllato per la creazione di versioni. Non più "John di solito costruisce sulla sua macchina ma è malato. Per qualche ragione non posso costruire sulla mia macchina"
• In questo momento ne ho installato uno in una sessione di Virtual PC.
• Sì. La build deve essere scaricata da qualche parte accessibile. Le build di sviluppo dovrebbero avere il debug attivato. La versione di rilascio dovrebbe essere disattivata.
• Quanto spesso dipende da te. Se impostato correttamente, è possibile compilare dopo ogni check in un sovraccarico molto piccolo. Questa è un'ottima idea se hai (o stai pianificando di avere) unit test in atto.
• Mantieni le pietre miliari e le pubblicazioni per tutto il tempo necessario. Qualcos'altro dipende da quanto spesso costruisci: continuamente? Buttar via. Quotidiano? Mantieni una settimana. Settimanalmente? Mantieni due mesi.

Più grande è il tuo progetto, più vedrai i vantaggi di una macchina di costruzione automatica.

Riguarda la salute della build. Ciò che ti dà è che puoi impostare qualsiasi tipo di cose che vuoi che accadano con le build. Tra questi è possibile eseguire test, analisi statiche e profiler. I problemi vengono risolti molto più rapidamente, quando di recente hai lavorato su quella parte dell'applicazione. Se commetti piccole modifiche, allora ti dice quasi dove l'hai rotto :)

Questo ovviamente presuppone che tu lo abbia impostato per compilare ad ogni check-in (integrazione continua).

Può anche aiutare ad avvicinare QA e Dev. Come è possibile impostare test funzionali per l'esecuzione con esso, insieme a profiler e qualsiasi altra cosa che migliora il feedback per il team di sviluppo. Questo non significa che i test funzionali vengano eseguiti ad ogni check-in (può richiedere del tempo), ma si creano build / test con strumenti comuni a tutto il team. Ho automatizzato i test del fumo, quindi nel mio caso collaboriamo ancora più da vicino.

Perché: 10 anni fa noi sviluppatori di software analizzavamo all'ennesima potenza i documenti (scritti in un linguaggio umano) "firmati", quindi iniziavamo a scrivere codice. Avremmo test unitario, test delle stringhe e poi avremmo superato il test di sistema: la prima volta che il sistema nel suo insieme sarebbe stato eseguito insieme, a volte una settimana o mesi dopo aver ottenuto la firma dei documenti. Solo allora scopriremo tutti i presupposti e le incomprensioni che abbiamo avuto quando abbiamo analizzato tutto.

L'integrazione continua come e l'idea ti porta a costruire un sistema completo (sebbene, inizialmente, molto semplice) end-to-end. Nel tempo la funzionalità del sistema è stata sviluppata ortogonalmente. Ogni volta che esegui una build completa, esegui il test di sistema in anticipo e spesso. Ciò significa che è possibile trovare e correggere bug e ipotesi il più presto possibile, quando è il momento più economico per risolverli.

Come: Per quanto riguarda il come, ho scritto un blog su questo poco tempo fa: [ Clicca qui ]

Oltre 8 post spiega come configurare un server Jenkins in un ambiente Windows per soluzioni .NET.