Integrazione continua con Hudson

L'integrazione continua è diventata una pratica comune per i team impegnati a garantire la qualità del codice durante l'intero ciclo di vita dello sviluppo del software. In questo articolo, Nicholas Whitehead introduce Hudson, un popolare server CI open source. Scopri come configurare un server Hudson nel tuo ambiente di sviluppo dell'applicazione (vengono forniti esempi per Windows XP con Tomcat 6 o Ubuntu Linux con JBoss AS), ottieni una panoramica delle numerose opzioni di configurazione fornite da Hudson, quindi implementa una build automatizzata, test, e processo di reporting per un progetto di esempio. Livello: principiante

L'integrazione continua (CI) è un insieme di pratiche intese a facilitare e stabilizzare il processo di creazione di build software. CI assiste i team di sviluppo nelle seguenti sfide:

  • Automazione della compilazione del software : con CI, è possibile avviare il processo di creazione di un artefatto software con la semplice pressione di un pulsante, in base a una pianificazione predefinita o in risposta a un evento specificato. Se desideri creare un artefatto software dall'origine, il tuo processo di compilazione non è vincolato a un IDE, computer o persona specifici.
  • Verifica continua automatizzata della build : un sistema CI può essere configurato per eseguire costantemente build man mano che viene archiviato il codice sorgente nuovo o modificato. Ciò significa che mentre un team di sviluppatori software controlla periodicamente il codice nuovo o modificato, il sistema CI verifica continuamente che la build non viene interrotto dal nuovo codice. Ciò riduce la necessità per gli sviluppatori di verificare tra loro le modifiche ai componenti interdipendenti.
  • Test di build automatici continui : un'estensione della verifica della build, questo processo garantisce che il codice nuovo o modificato non causi il fallimento di una suite di test predefiniti sugli artefatti creati. Sia nella verifica della build che nei test, gli errori possono attivare notifiche alle parti interessate, indicando che una build o alcuni test hanno fallito.
  • Automazione della procedura di post-compilazione : il ciclo di vita della build di un artefatto software può anche richiedere attività aggiuntive che possono essere automatizzate una volta completate la verifica e il test della build, come la generazione della documentazione, il confezionamento del software e la distribuzione degli artefatti in un ambiente repository di software. In questo modo gli artefatti possono essere resi rapidamente disponibili agli utenti.

Per implementare un server CI è necessario, come minimo, un repository di codice sorgente accessibile (e il codice sorgente in esso contenuto), una serie di script e procedure di compilazione e una suite di test da eseguire sugli artefatti compilati. La figura 1 delinea la struttura di base di un sistema CI.

I componenti del sistema entrano in gioco nella seguente sequenza:

  1. Gli sviluppatori controllano il codice nuovo e modificato nel repository del codice sorgente.
  2. Il server CI crea uno spazio di lavoro dedicato per ogni progetto. Quando viene richiesta o pianificata una nuova build, l'origine viene recuperata dal repository in questo spazio di lavoro, dove viene quindi eseguita la build.
  3. Il server CI esegue il processo di compilazione nell'area di lavoro appena creata o aggiornata.
  4. Una volta completata la compilazione, il server CI può facoltativamente richiamare la suite di test definita sui nuovi artefatti. Se la compilazione non riesce, le persone registrate possono ricevere una notifica tramite e-mail, messaggistica istantanea o altri metodi.
  5. Se la compilazione ha esito positivo, le risorse vengono impacchettate e trasmesse a una destinazione di distribuzione (come un server delle applicazioni) e / o archiviate come una nuova risorsa con versione in un repository software. Questo repository può far parte del server CI o potrebbe essere un repository esterno, come un file server o un sito di distribuzione software come Java.net o SourceForge. Il repository del codice sorgente e il repository degli artefatti possono essere separati ed è effettivamente possibile utilizzare alcuni server CI senza alcun sistema formale di controllo del codice sorgente.
  6. I server CI di solito hanno una sorta di console in cui è possibile configurare ed eseguire il debug dei progetti e in cui è possibile inviare richieste per operazioni quali build immediate ad hoc, generazione di report o recupero di artefatti compilati.

Hudson: un server di integrazione continua

L'integrazione continua è diventata popolare negli ultimi anni e oggi hai un bel po 'di server CI tra cui scegliere, sia commerciali che gratuiti. Personalmente avevo utilizzato quattro server CI prima che un collega mi suggerisse di guardare Hudson. Ne sono stato subito colpito. Sebbene inizialmente pensassi che Hudson non fosse molto conosciuto, un sondaggio sul sito Java Power Tools lo mostra come il server CI più utilizzato tra gli intervistati, ottenendo (al momento della stesura di questo documento) il 37,8% di tutti i voti.

SCM supportati

Hudson ha il supporto integrato per Subversion immediatamente e solo una piccola quantità di configurazione è richiesta per l'integrazione con CVS, supponendo che il client CVS sia installato sull'host Hudson. Diverse altre soluzioni di gestione del codice sorgente (SCM) sono supportate sotto forma di plug-in Hudson. Al momento della stesura di questo documento, sono supportati i seguenti SCM:

  • Accurev
  • BitKeeper
  • ClearCase
  • Idiota
  • Mercurial
  • Perforce
  • StartTeam
  • Team Foundation Server
  • Visual SourceSafe
  • URL SCM (uno speciale plug-in SCM che consente l'uso di URL per SCM)

In questo articolo, userò Subversion e il repository dei sorgenti su Java.net, quindi non sarà necessario installare nessuno di questi plugin. (Per inciso, conosco qualcuno che sta lavorando a un plug-in MKS SourceIntegrity Hudson. Se ti interessa, inviami un'e-mail.)

Hudson è un prodotto gratuito e open source ospitato su Java.net. È stato originariamente scritto da Kohsuke Kawaguchi, un ingegnere dello staff di Sun Microsystems, che ha annunciato il suo rilascio sul suo blog nel febbraio del 2005. Hudson da allora ha avuto circa 154 versioni.

Ecco alcuni dei motivi per cui mi piace Hudson e perché te lo consiglierei, salvo requisiti insoliti:

  • Di tutti i prodotti CI che ho usato, è di gran lunga il più facile da installare e configurare.
  • Le sue interfacce utente basate sul Web sono molto amichevoli, intuitive e reattive, in molti casi forniscono un feedback immediato abilitato per Ajax sui singoli campi di configurazione.
  • Hudson è basato su Java (che è utile se sei uno sviluppatore Java) ma non si limita alla creazione di software basato su Java.
  • Hudson è composto in modo pulito e offre un'API di estensibilità ben definita e documentata sotto forma di plug-in Hudson. Ciò ha portato a sua volta a una vasta libreria di plugin Hudson che estendono le funzionalità del server; questi sono disponibili gratuitamente e installabili dalla console Hudson.

Installazione di Hudson: Windows XP o Ubuntu Linux

Per utilizzare Hudson, avrai bisogno di un sistema di controllo del codice sorgente accessibile e supportato (vedi la barra laterale "SCM supportati" per un elenco), sorgente che può essere incorporata in un artefatto e uno script di build funzionante. Oltre a ciò, tutto ciò di cui hai veramente bisogno per installare e configurare un server Hudson funzionante è un'installazione di Java, versione 1.5 o successiva, e il file di installazione di Hudson, che si presenta sotto forma di un archivio Web Java EE (WAR). È possibile avviare il server molto semplicemente utilizzando la seguente riga di comando:

C:\hudson> java -jar hudson.war

È probabilmente più comune, tuttavia, distribuire Hudson su un contenitore servlet Java basato sulle specifiche Servlet 2.4 e JSP 2.0, come GlassFish, Tomcat, JBoss o Jetty. Nelle sezioni successive, ti guiderò attraverso due scenari di installazione di Hudson: uno utilizzando Tomcat 6 su Windows XP e un altro utilizzando JBoss 4.2.3 su Ubuntu Linux. (JBoss AS 5.0 è stato rilasciato dopo la data di invio di questo articolo.)

Installazione di Hudson: Tomcat 6 e Windows XP

Presumo che tu abbia già la versione 1.5 o successiva di Java installata sulla tua macchina Windows XP. Seguendo i passaggi seguenti verrà installato Tomcat 6.0.18 utilizzando Windows Service Installer, in modo che Hudson si avvii immediatamente dopo l'avvio di Windows XP e verrà eseguito in background anche quando nessun utente è connesso. Il file di download per Tomcat è apache-tomcat- 6.0.18.exe, che è necessario eseguire per avviare l'installazione di Tomcat.

L'installazione di Tomcat ti chiederà di selezionare le opzioni di installazione. Assicurati di selezionare Opzioni personalizzate e poi Servizio , come mostrato nella Figura 2, in modo che Tomcat venga eseguito come servizio.

Successivamente, seleziona una directory in cui desideri installare Tomcat, come mostrato nella Figura 3. Consiglio vivamente di scegliere una directory senza spazi. Puoi ringraziarmi più tardi.

Ora il programma di installazione ti chiederà su quale porta desideri ascoltare. L'impostazione predefinita è la porta 8080, che probabilmente va bene; assicurati solo di non avere un'altra applicazione che utilizza quella porta. Se lo fai, Tomcat non si avvierà correttamente. Ti verrà inoltre chiesto di fornire un nome utente e una password di amministratore Tomcat. Tutto questo è mostrato nella Figura 4.

Il programma di installazione ti chiederà quindi di fornire la posizione del Java JRE che hai installato. Come puoi vedere nella Figura 5, ho usato Sun Java 1.6.0_07.

Dopo aver fatto clic su Installa , l'installazione dovrebbe essere completata e il servizio inizierà a funzionare. È possibile assicurarsi che Tomcat funzioni correttamente puntando il browser Web su // localhost: 8080 (sostituendo il nome o l'indirizzo IP appropriato per localhost se non si utilizza un browser Web in esecuzione sul computer in cui è installato Tomcat). La pagina Web visualizzata dovrebbe essere simile allo screenshot nella Figura 6.

Ora, per installare Hudson, copia il file hudson.war nella sottodirectory webapps della directory di installazione di Tomcat. Se hai utilizzato la stessa directory di installazione mostrata nella Figura 3, questa sarebbe C: \ Tomcat6 \ webapps. Tomcat distribuirà a caldo i file WAR, ma la cosa più semplice da fare ora è riavviare Tomcat. Ci sono due modi per farlo. Il primo è aprire una shell DOS e immettere i seguenti comandi:

 C:\Tomcat6>net stop Tomcat6 C:\Tomcat6>net start Tomcat6

La seconda opzione è aprire l'applet Servizi. Questa applet si trova nel gruppo Strumenti di amministrazione nel Pannello di controllo, che può essere individuato facendo clic sul pulsante Start sulla barra degli strumenti di Windows, quindi selezionando Impostazioni e quindi Pannello di controllo . Nell'applet Servizi, individuare il servizio denominato Apache Tomcat e quindi fare clic sul pulsante Riavvia . Ciò è illustrato nella Figura 7.

Hudson dovrebbe ora essere installato. È possibile verificarlo puntando il browser Web su // localhost: 8080 / hudson. La schermata principale di Hudson è mostrata nella Figura 8.

È tutto quello che c'è da fare! Se sei a tuo agio con un ambiente di sviluppo di applicazioni basato su Windows XP e Tomcat, sei pronto. Se preferisci un sistema che esegue JBoss e Ubuntu Linux, continua a leggere.

Installazione di Hudson: JBoss 4.2.3 su Ubuntu Linux 8.04 (Hardy Heron)

Per installare Sun Java 1.6 su Ubuntu, apri una shell ed esegui il seguente comando:

 sudo apt-get install sun-java6-jdk

Quando si emette un sudocomando, verrà richiesto di inserire la password.

Nota che ci sono diversi modi per installare JBoss; nella tecnica qui delineata, creerai un jbossutente dedicato . Questa è considerata una best practice ed è preferibile all'installazione di JBoss nella tua home directory. La procedura qui delineata è stata condensata da un'utile descrizione nei forum di Ubuntu.

Innanzitutto, è necessario scaricare il pacchetto JBoss 4.2.3.GA. Cerca il file denominato jboss-4.2.3.GA.zip.

Next, you will need to create a user, a home directory, and a group, all named jboss. The group is a convenience not explored in this article; it will allow you to extend JBoss privileges to other users on your Ubuntu server.

Listing 1 shows the commented commands to create the jboss home directory, user, and group, and then install the JBoss server. Some commands are prefixed with sudo because they are root-privileged commands.

Listing 1. Creating the jboss account and installing the server

echo Create the jboss group sudo groupadd jboss echo Create the jboss user, define bash as the user's default shell and /home/jboss as the home directory echo and make the user jboss part of the group jboss sudo useradd -s /bin/bash -d /home/jboss -m -g jboss jboss echo Copy the jboss-4.2.3.GA file to /home/jboss or download directly into that directory sudo mv jboss-4.2.3.GA /home/jboss echo Change the owner of the file to jboss sudo chown jboss:jboss /home/jboss/jboss-4.2.3.GA echo Log into the jboss account sudo su jboss echo Go to the jboss home directory cd ~ echo Unzip the file jboss-4.2.3.GA unzip jboss-4.2.3.GA echo Create a symbolic link "jboss" for "jboss-4.2.3.GA". echo This allows you to change JBoss versions with minimal changes ln -s jboss-4.2.3.GA jboss

If the unzip command is not already installed, enter the following command (while logged in as a sudo-enabled user) to install it:

Sudo apt-get install unzip

The JBoss server is now basically installed. You could start the server using the following command:

/home/jboss/jboss/bin/run.sh

In questo esempio, tuttavia, installerai invece uno script di avvio automatico in modo che il servizio si avvii automaticamente all'avvio dell'host. Il download di JBoss viene fornito con tre diversi script int.d, ma ciascuno deve essere ottimizzato; puoi scaricare lo script jboss-init.sh, che abiliterà l'avvio e l'arresto automatico del server. Quindi esegui i comandi mostrati nel listato 2.