JOOMLA & I PROJECT BUILD AUTOMATION

Transcript

1 JOOMLA & I PROJECT BUILD AUTOMATION by Luglio 2013 Autori Giampaolo Losito Antonio Di Girolamo 1

2 SOMMARIO Prefazione... 3 Requisiti... 3 Un Project Build Automation... 3 Glossario dei termini... 4 Creare il build.xml... 4 Il task Project... 6 Porzione di codice: Definizione progetto... 6 Porzione di codice: Task property... 7 Il target main... 8 Porzione di codice: Target main... 8 Il target init... 9 Porzione di codice: Target init... 9 Il target admin Porzione di codice: Target admin Il target site Porzione di codice: Target admin Il target package Porzione di codice: Target package Project Build in esecuzione Riferimenti On-line

3 PREFAZIONE Dopo aver descritto l utilizzo di un sistema di versionamento per la gestione del codice dei progetti Joomla!, in questa guida affronteremo l argomento dei project-build automation, strumento che serve ad accelerare i tempi di rilascio delle proprie creazioni in Joomla!. I project-build automation permettono di realizzare una quantità elevata di processi automatizzati, dalla chiamata alle UnitTest alla gestione dei dati e delle strutture dati di un DB in modo automatico. In questa guida utilizzeremo il projecg-build automation per la creazione automatica dei pacchetti di installazione delle nostre componenti, moduli o plugin per Joomla!. REQUISITI Per la lettura di questa guida, pertanto, sono necessari alcuni requisiti di base, ossia, un Project Build Automation, una buona conoscenza di XML e una discreta conosceza di PHP in caso si voglia estendere il Project Build che utilizzeremo nel proseguo dell articolo. UN PROJECT BUILD AUTOMATION Un project-build automation è un sistema di deploy che permette di pubblicare i propri progetti in modo pratico e veloce. Grazie a questo, oltre ad abbattere i tempi dei rilasci, permette di diminuire gli errori di eventuali deploy manuali. Esistono molti project-build automation. Tra i più utilizzati e famosi menzioniamo, Apache Ant e Maven scritti in Java e il build-automation Phing, che utilizzeremo per questa guida. Abbiamo scelto Phing (nato dal porting di Apache Ant), perché è un sistema di project-build automation scritto interamente in PHP e quindi molto più vicino al mondo Joomla!. Inoltre molti degli step di deploy sono facilmente realizzabili attraverso la configurazione di un file XML ed eventualmente, altri step possono essere creati ad hoc estendendo Phing con nuove classi scritte anche esse in PHP. In questa guida, non entreremo nel dettaglio della installazione di Phing, questa è ben documentata nella sezione Tips e Tricks del nostro portale e sul sito ufficiale (vedi riferimenti on-line), dove è possibile anche scaricare l ultima versione di Phing. In caso si disponga e si utilizzi per il proprio ambiente di sviluppo XAMPP, quest ultimo supporta già una versione di Phing, presente nella cartella PEAR di PHP. 3

4 GLOSSARIO DEI TERMINI File di build: File XML contenente i target ed i task di esecuzione della build. Target: Contenitore di un insieme di task. Task: Istruzione(copia, cancella, sposta, crea ) presente in un Target. CREARE IL BUILD.XML Come sempre spiegheremo l utilizzo e funzionamento di questo metodologia di build, con un esempio reale. In questo caso abbiamo preso come esempio la struttura di JPhoto Mobile. Nella parte finale della guida, su come utilizzare un sistema di versionamento per i progetti Joomla!, siamo arrivati all esportazione dei sorgenti in una cartella. A questo punto possiamo intervenire con un sistema di build-project automation per creare il nostro pacchetto di installazione senza dover, ogni volta, impazzire a spostare, copiare ed eliminare file, cartelle o quant altro in modo manuale. Di seguito è riportata la struttura (sono state riportate le sole cartelle per semplificare l immagine) del progetto che abbiamo appena esportato dal nostro trunk e che contiene tutti i file e le cartelle del nostro progetto. 4

5 Figura 1 A questo punto cominciamo a costruire il nostro file di build. Phing per poter funzionare necessita di un file di build, un semplice file XML, richiamabile da linea di comando. > phing f nomedelbuildfile.xml targeteseguibile In caso non venga specificato il build file, il sistema cercherà il file build.xml che dovrà essere presente nella stesso percorso dove punta il prompt dei comandi. Il secondo parametro è il Target che vogliamo eseguire. Se omesso il sistema recupera quello di default definito nel tag <project>. Apriamo un file vuoto, al di fuori della cartella trunk, e nominiamolo build.xml. 5

6 Figura 2 Il file di build è un file XML suddiviso in raggruppamenti di comandi (Task) chiamati Target che definiscono il processo di build. IL TASK PROJECT Il seguente task serve alla definione del progetto nel file di build. PORZIONE DI CODICE: DEFINIZIONE PROGETTO <?xml version="1.0" encoding="utf-8"?> <project name="joomphoto Mobile 2.3" default="main"> Nella precedente riga abbiamo definito il nome del progetto e il Target di default (attributo default ), nel nostro caso il Target main, che verrà chiamato per primo, utilizzando il task project nella forma: <project name=" " default=" "> A questo punto si possono definire delle proprietà richiamabili nel file di build. Le proprietà sono delle costanti che possono essere definite in tre modi: Tramite il tag <property> direttamente nel file di build Passandole da linea di comando Utilizzando un file di configurazione esterno (strutturato come un file di properties di Java) Nel nostro esempio abbiamo preferito utilizzare il task property nella forma: <property name= value= > E importante anche fare presente che per richiamare una property in un altro task si utilizza la forma: ${nameproperty} 6

7 PORZIONE DI CODICE: TASK PROPERTY <property name="packagename" value="com_joomphotomobile_2.3-j25_j3" /> <property name="export" value="./trunk" /> <property name="admindirectory" value="${export}/administrator" /> <property name="admincomponentdir" value="${admindirectory}/components/com_joomphotomobile" /> <property name="sitecomponentdir" value="${export}/components/com_joomphotomobile" /> <property name="builddir" value="./${packagename}" /> <property name="admindir" value="${builddir}/admin" /> <property name="sitedir" value="${builddir}/site" /> Con queste proprietà abbiamo definito: il nome del pacchetto da creare: "packagename" la cartella dove sono presenti i sorgenti esportati: "export". Si può notare che si è utilizzata la definizione del path come./nomedir. Questa notazione definisce che la cartella trunk si trova nella stessa directory del file di build. la cartella di amministrazione dei sorgenti esportati: "admindirectory" la cartella della componente di amministrazione dei sorgenti esportati: "admincomponentdir" la cartella della componente di frontend dei sorgenti esportati: "sitecomponentdir " il nome della cartella che verà creata per il pacchetto di installazione: "builddir" la cartelle dovre dovranno essere installati gli script di amministrazione: "admindir" la cartelle dovre dovranno essere installati gli script di frontend: "sitedir " Si possono definire e utilizzare property a seconda delle esigenze e necessità. Il passo successivo ora è quello di definire i target. Si potrebbe creare un unico target di creazione del pacchetto, ma per una migliore lettura del file di Build si è pensato di separare i Target, così come si sarebbe proceduto con un processo manuale della creazione del pacchetto di installazione. 7

8 Come già descritto, il primo Target che verrà richiamato è quello definito nel Tag <project> nell attributo default ovvero il Target: main. IL TARGET MAIN Questo target non fa altro che definire le dipendenze, ovvero, definisce la sequenza dei Target che verranno richiamati a partire da sinistra verso destra. Dato che abbiamo separato i nostri target per una migliore manutenzione del file di build, ogni target presenta una possibile dipendenza, ovvero il target non viene eseguito se prima non vengono eseguiti i target da cui dipende. Questa informazione viene data al sistema di build mediante la definizione dell attributo depends. Nel l attributo depends è possibile definire più Target, separati dal carattere di virgola. Il sistema eseguirà questi Target, in modo sequenziale, partendo dal primo elemento, a partire da sinistra, presente nell attributo. Come si legge dalla porzione di file XML sotto riportata, dall attributo depends del target main, il sistema chiamerà in sequenza i seguenti Target: 1. init 2. admin 3. site 4. package Al termine dell ultimo Target, nel nostro caso packages, il sistema eseguirà il Target chiamante, ovvero il Target main. Questo Target non fa altro che avvisarci con un messaggio a video che il pacchetto è stato creato correttamente. Per definire dei messaggi che dovranno essere visualizzati a video si utilizza il task echo nella forma: <echo msg= /> msg: stringa del messaggio PORZIONE DI CODICE: TARGET MAIN <!-- Target: main (DEFAULT) --> <!-- Definisce i target da richiamare in sequenza --> 8

9 <target name="main" depends="init, admin, site, package"> </target> <echo msg="build Project di JoomPhoto Mobile Terminato con successo" /> IL TARGET INIT Come già descritto, la prima dipendenza del Target main è il target init. Questo Target crea la cartella dove verrà effettuato il deploy di tutti i file per la creazione del pacchetto, ovvero la root del pacchetto di installazione della componente Joomla! (com_joomphotomobile_2.3-j25_j3) e copia in questa cartella i file utilizzati da Joomla! per l installazione: install.joomphotomobile.php joomphotomobile.xml Per la creazione di una nuova directory si è utilizzato il task mkdir nella forma: <mkdir dir=" " /> dir: path della directory da creare Per la copia dei file abbiamo utilizzato il task copy nella forma: <copy file=" " tofile=" " /> file: path (compreso il nome del file) del file da copiare tofile: path (compreso il nome del file) dove copiare il file PORZIONE DI CODICE: TARGET INIT <!-- Target: init --> <!-- Crea la cartella di del package --> <target name="init"> <echo msg="crea directory di BUILD..." /> <mkdir dir="${builddir}" /> 9

10 </target> <echo msg="copia dei file di installazione nella directory di build..." /> <copy file="${admincomponentdir}/install.joomphotomobile.php" tofile="${builddir}/install.joomphotomobile.php" /> <copy file="${sitecomponentdir}/joomphotomobile.xml" tofile="${builddir}/joomphotomobile.xml" /> IL TARGET ADMIN Questo target costruisce la struttura della cartella admin. Va ricordato che la struttura da creare deve essere conforme al manifest di installazione della propria componente. Nel nostro caso dobbiamo copiare la cartella di amministrazione e quella dove sono presenti i file delle lingue della componente. Per la copia della cartella di amministrazione abbiamo utilizzato il task copy nella forma: <copy todir= > </copy> todir: path della directory dove verranno copiati tutti i file o directory. Se non esiste il sistema la crea Per la copia di tutta la struttura della cartella di amministrazione e delle lingue si è utilizzato il task fileset, all interno del task copy, nella forma: <fileset dir= > </fileset> dir: path della directory da copiare Data la necessità di escludere alcuni file nella copia, all interno del task fileset, si è utilizzato il task exclude nella forma: <exclude name= /> name: path (compreso di nome) del file da escludere dalla copia Mentre per copiare tutti i file e cartelle si è tilizzato il task patternset nella forma: <patternset><include name= ** /></pattern set> 10

11 name: espressione regolare per la selezione dei file. Se definito ** allora copia tutti i file e cartelle a meno di quelli definiti del task exclude. PORZIONE DI CODICE: TARGET ADMIN <!-- Target: admin --> <!-- Creazione della cartella "Admin" contenente --> <!-- la parte di cartelle e file per il BackEnd --> <target name="admin"> <echo msg="build della parte di amministrazione (administrator)..." /> <echo msg="inizio copia dei file nella directory admin..." /> <copy todir="${admindir}" > </copy> <fileset dir="${admincomponentdir}" > </fileset> <exclude name="install.joomphotomobile.php" /> <patternset> <include name="**"/> </patternset> <copy todir="${admindir}/language" > </copy> <fileset dir="${admindirectory}/language" > </fileset> <patternset> <include name="**"/> </patternset> 11

12 </target> IL TARGET SITE Questo target come per il target admin costruisce la struttura della cartella site così come descritta nel manifest. Anche per questo target si sono utilizzati gli stessi task descritti nel target admin. PORZIONE DI CODICE: TARGET ADMIN <!-- Target: site --> <!-- Creazione della cartella "Site" contenente la --> <!-- parte di cartelle e file per il FronEnd --> <target name="site"> <echo msg="build della parte di fronend..." /> <echo msg="copia dei file nella directory site..." /> <copy todir="${sitedir}" > </copy> <fileset dir="${sitecomponentdir}" > </fileset> <patternset> <include name="**"/> </patternset> <copy todir="${sitedir}/language" > <fileset dir="${export}/language" > </fileset> <patternset> <include name="**"/> </patternset> 12

13 </target> </copy> IL TARGET PACKAGE Questo target definisce il processo della creazione del pacchetto di installazione per Joomla!. Per la creazione dell archivio in formato ZIPsi è utilizzato il task zip nella forma: <zip destfile= > </zip> destfile: path (compreso di nome) dell archivio da creare Al termine del processo si potrebbe, come nel nostro caso cancellare la cartella di build per risparmiare spazio. Per questo si è utilizzato il task delete nella forma: <delete dir= /> dir: path della directory da cancellare PORZIONE DI CODICE: TARGET PACKAGE <!-- Target: pacakge --> <!-- Crea il pacchetto di installazione --> <target name=" package" > <echo msg="creazione dell archivio..." /> <zip destfile="./${packagename}.zip"> </zip> <fileset dir="${builddir}"> </fileset> <include name="**/**" /> 13

14 <echo msg="file copiati e compressi nella build directory..." /> <echo msg="cancella cartella di Build..." /> <delete dir="${builddir}"/> </target> PROJECT BUILD IN ESECUZIONE C:\build-JPM>phing Buildfile: C:\build-JPM\build.xml JoomPhoto Mobile 2.3 > init: [echo] Crea directory di BUILD... Ora accediamo alla shell del sistema operativo e posizioniamoci nella cartella dove è presente il nostro trunk e il file di build appena creato. Richiamiamo Phing. Come già descritto se non definito un file di build, Phing cerca il file build.xml presente nella cartella. Nel nostro caso presente nella cartella build-jpm. Durante il build il sistema visualizza a video gli echo inseiti ed eventuali informazioni stampate a video da parte dei task utilizzati. [mkdir] Created dir: C:\build-JPM\com_joomphotomobile_2.3-j25_j3 [echo] Copia dei file di installazione nella directory di build... [copy] Copying 1 file to C:\build-JPM\com_joomphotomobile_2.3-j25_j3 [copy] Copying 1 file to C:\build-JPM\com_joomphotomobile_2.3-j25_j3 JoomPhoto Mobile 2.3 > admin: [echo] Build della parte di amministrazione (administrator)... [echo] Inizio copia dei file nella directory admin... [copy] Created 13 empty directories in C:\build-JPM\com_joomphotomobile_2.3-j25_j3\admin [copy] Copying 44 files to C:\build-JPM\com_joomphotomobile_2.3-j25_j3\admin [copy] Created 3 empty directories in C:\build-JPM\com_joomphotomobile_2.3-25_j3\admin\language [copy] Copying 4 files to C:\build-JPM\com_joomphotomobile_2.3-j25_j3\admin\language JoomPhoto Mobile 2.3 > site: [echo] Copying files to site directory... [echo] Copia dei file nella directory... 14

15 [copy] Created 7 empty directories in C:\build-JPM\com_joomphotomobile_2.3-j25_j3\site [copy] Copying 24 files to C:\build-JPM\com_joomphotomobile_2.3-j25_j3\site [copy] Created 3 empty directories in C:\build-JPM\com_joomphotomobile_2.3-j25_j3\site\ language [copy] Copying 2 files to C:\build-JPM\com_joomphotomobile_2.3-j25_j3\site\language JoomPhoto Mobile 2.3 > package: [echo] Creating archive... [zip] Building zip: C:\build-JPM\com_joomphotomobile_2.3-j25_j3.zip [echo] File copiati e compressi nella build directory [delete] Deleting directory C:\build-JPM\com_joomphotomobile_2.3-j25_j3 JoomPhoto Mobile 2.3 > main: [echo] Build Project di JoomPhoto Mobile Terminato con successo BUILD FINISHED Total time: seconds Al termine del processo, nel nostro caso durato solo 30 secondi, troveremo pronto il pacchetto di installazione della nostra componente per Joomla!. A questo punto dopo ogni piccola correttiva, bugfix o evolutiva basterà solo richiamare Phing ed il pacchetto è pronto. 15

16 RIFERIMENTI ON-LINE