Allestire un ambiente di sviluppo

8/4/2019 Allestire un ambiente di sviluppo

1/8

CP pensareprogettareprogrammare n. 134 aprile 2004

Allestire un ambiente di sviluppodi Stefano Fornari

Allestire un ambiente di lavoro completo per un team di sviluppo prevede la scelta di sistemihardware e diversi software. Si possono tuttavia conseguire ottimi risultati a un costo piu cheragionevole

Stefano Fornari

E CTO di Funambol,startup focalizzata nel-lo sviluppo di midd-leware per il wirelessdata synchronization.


2/8

pubblicato suWWW.INFOMEDIA.IT

stampa digitale da

Lulu Enterprises Inc.

stores.lulu.com/infomedia

Infomediamedia e limpresa editoriale che da quasi venti an-

a raccolto la voce dei programmatori, dei sistemi-

dei professionisti, degli studenti, dei ricercatori e dei

essori dinformatica italiani.

o piu di 800 gli autori che hanno realizzato per le te-

Computer Programming, Dev, Login, Visual Basic

nal e Java Journal, molte migliaia di articoli tecnici,

entazioni di prodotti, tecnologie, protocolli, strumen-lavoro, tecniche di sviluppo e semplici trucchi e stra-

mmi. Oltre 6 milioni di copie distribuite, trentamila

ne stampate, fanno di questa impresa la piu grande ed

ente realta delleditoria specializzata nel campo della

rammazione e della sistemistica.

tti questi anni le riviste Infomedia hanno vissuto del-

assione di quanti vedono nella programmazione non

la propria professione ma unattivita vitale e un vero

rtimento.

2009, Infomedia e cambiata radicalmente adottando

uovo modello aziendale ed editoriale e si e organiz-

attorno ad una idea di Impresa Sociale di Comunita,

ecipata da programmatori e sistemisti, separando le

ita di gestione dellinformazione gestite da un board

unitario professionale e quelle di produzione gesti-

a una impresa strumentale. Questo assetto e in linea

le migliori esperienze internazionali e rende Infome-

ancora di piu parte della Comunita nazionale degli

uppatori di software.

media e media-partner di manifestazioni ed eventi in

ito informatico, collabora con molti dei pi u impor-

editori informatici italiani come partner editoriale e

itore di servizi di localizzazione in italiano di testi in

ua inglese.

aginazione automatica di questa rivista e realizzata al

% con strumenti Open Source usando OpenOffice,

cs, BHL, LaTeX, Gimp, Inkscape e i linguaggi Lisp,

hon e BASH

copyright information about the contents of Compu-

Programming, please see the section Copyright at

end of each article if exists, otherwise ask authors.media contents is 2004 Infomedia and released as

ative Commons 2.5 BY-NC-ND. Turing Club content

2004 Turing Club released as Creative Commons

BY-ND.

nformazioni di copyright sul contenuto di Computer

gramming sono riportate nella sezione Copyright

fine di ciascun articolo o vanno richieste direttamen-

gli autori. Il contenuto Infomedia e 2004 Infome-

e rilasciato con Licenza Creative Commons 2.5 BY-

ND. Il contenuto Turing Club e 2004 Turing Club

asciato con Licenza Creative Commons 2.5 BY-ND.

pplicano tuttele normedi tuteladeimarchie deisegni

ntivi.

ogni caso ammessa la riproduzione parziale o tota-

ei testi e delle immagini per scopo didattico purche

gano integralmente citati gli autori e la completa

tificazione della testata.

oscritti e foto originali, anche se non pubblicati, non

stituiscono.

tenuto pubblicitario inferiore al 45%.

biografia dellautore riportata nellarticolo e sul

www.infomedia.it e di norma quella disponibi-

nella stampa dellarticolo o aggiornata a cu-

dellautore stesso. Per aggiornarla scrivere a

@infomedia.it o farlo in autonomia allindirizzo

//mags.programmers.net/moduli/biografia
http://www.infomedia.it/http://stores.lulu.com/infomediahttp://stores.lulu.com/infomediahttp://stores.lulu.com/infomediahttp://stores.lulu.com/infomediahttp://www.infomedia.it/


3/8

Computer Programming n.134 - Aprile 2004 19

Professione informatico

S

ulla scia del motto anno nuovo vita nuova, alli-nizio dellanno ho iniziato una nuova attivit,naturalmente legata allo sviluppo software. Tra i

mille problemi che ne conseguono, ho avuto ilcompito e il piacere di organizzare interamente ex-novolambiente di sviluppo. Ho cos potuto mettere a fruttovarie esperienze carpite qua e l durante lattivit di con-sulenza che ho prestato negli anni passati. Il compito punon essere semplice, ma si possono ottenere buoni risulta-ti con uno sforzo ragionevole. In questo articolo presente-r lorganizzazione dellambiente di lavoro in termini disistemi, software e procedure di sviluppo, senza per averela presunzione di considerarlo un ambiente ottimale o diriferimento.

Semplicemente, nel mio caso funziona, quindi credopossa funzionare anche in altre situazioni; oppure pu esse-re uno spunto per trovare soluzioni migliori.

Osservazioni preliminariPer inquadrare il tipo di esigenze e di ambiente di lavoro

necessario, utile accennare al tipo di sviluppo software danoi realizzato. Lazienda della quale sono direttore tecnicosi occupa dello sviluppo di un middleware Java per la sin-cronizzazione dati, il device management e lapplicationprovisioning. Fornisce inoltre supporto e consulenza perquanto riguarda le problematiche citate e il prodotto stes-so. Un aspetto fondamentale della piattaforma lo svilup-po di un portale di sincronizzazione che permette a svilup-patori di applicazioni e contenuti di mettere a disposizionei loro prodotti, lasciando allinfrastruttura del portale tutti

gli aspetti legati alla sincronizzazione dati. Sebbene il teamdi sviluppo sia al momento costituito da poche persone, nostra intenzione crescere molto rapidamente e quindilambiente di sviluppo deve essere pensato e predispostoper la gestione di gruppi di lavoro pi numerosi.

Nella mia esperienza ho trovato fondamentali diversitool e software per lo sviluppo, di cui elenco i pi impor-tanti:

IDE ed editor Version control system Bug tracking system

DBMS Application server Project builder

Backup

La lista pu naturalmente essere allungata a piacere, mai componenti elencati mi sembrano una buona dotazionealmeno per iniziare. E devo dire che rivolgendosi al merca-to, la suddetta dotazione pu esaurire tranquillamentebuona parte del budget dedicato al reparto tecnico. Quantoabbiamo speso? 0 (zero) dollari, euro, lire o qualsiasi valu-ta vorrete considerare! Ebbene s, possibile organizzare unintero ambiente di sviluppo con soli software open source,senza spendere un centesimo e, nella mia esperienza, senzarinunciare ad affidabilit ed efficienza (anzi!).

Dal punto di vista hardware, dove invece non c possi-bilit di non spendere nulla, ho ottenuto dal mio CEO treserver, di cui due dedicati allo sviluppo, mentre gli svilup-patori possono scegliere la piattaforma che preferiscono.Attualmente sviluppiamo su computer portatili e sistemaoperativo Windows XP.

Nelle prossime sezioni verranno descritti pi accurata-mente la configurazione di sistema, i singoli software e ilprocesso di sviluppo adottati. Per ulteriori approfondimen-ti la rete una miniera inesauribile di risorse, quindi doveopportuno segnaler i link utili.

Architettura di sistemaCome gi accennato, lambiente di sviluppo, da un

punto di vista hardware, costituito da una rete locale a

cui sono stabilmente collegati i tre server e a cui si colle-gano i portatili quando arriviamo in ufficio. La scelta deiportatili come computer di sviluppo dettata da motivi dicomodit e flessibilit. possibile lavorare da casa senzaproblemi e non necessario avere una postazione fissa inufficio. Nellottica di avere un team di sviluppo numeroso,in cui non tutte le persone sono generalmente presenti inufficio tutti i giorni, questo si traduce in una notevole otti-mizzazione delle risorse fisiche dellufficio stesso (scriva-nie, sedie, apparecchi di rete, ecc.).

I server hanno compiti ben definiti: un file/web server,un server di sviluppo e un server di QA (quality assuran-ce). Il file/web server il principale server di servizi, chefornisce tutte le funzionalit necessarie al buon funziona-

mento della rete locale, favorendo e ottimizzando la gestio-ne delle risorse condivise. Funziona quindi da serbatoiodi memoria di massa con i suoi due dischi da 120 Gb lunoed esegue servizi di database per le applicazioni, di web email server, DNS, ecc.

FOCUS

Allestire un ambiente

di sviluppoAllestire un ambiente di lavoro completo per un team di sviluppo prevede la scelta di sistemi hardwaree diversi software. Si possono tuttavia conseguire ottimi risultati a un costo pi che ragionevole

di Stefano Fornari

Stefano Fornari

CTO di Funambol, startup focalizzata nello sviluppo di middlewareper il wireless data synchronization.

[email protected]


4/8

FOCUS

20 Computer Programming n. 134 - Aprile 2004

Il server di sviluppo invece dedicato allo sviluppo vero

e proprio e in particolare ai build del prodotto. In unambiente di sviluppo con pi sviluppatori, come vedremonel seguito, i singoli programmatori lavorano generalmen-te in locale, su parti specifiche dellapplicazione. pernecessario avere una macchina di riferimento, su cui ci siasempre lultimo build e a cui tutti i membri del team pos-sano accedere per verificare che le funzionalit sviluppatefunzionino correttamente e siano integrate nel modo giu-sto nel build del giorno. Il server di sviluppo ospita anchesoftware server e non, che non conveniente o possibileinstallare sulle singole postazioni di sviluppo, per esempiodatabase o software di integrazione.

Il server di QA dimensionato per ospitare un partico-lare build a scopo di test, sia di performance e carico che diverifica della qualit. Generalmente questa macchina deveessere una sorella di una eventuale macchina di produ-zione, in quanto, soprattutto nel caso dei test di perfor-mance e carico, deve fornire dati che possano essere messiin relazione con la macchina di produzione. In un ambien-te pi complesso sarebbe in realt necessaria unaltra mac-china, detta di staging, sorella gemella dellambiente diproduzione. In questo caso fondamentale che la similari-t delle due macchine sia la pi vicina possibile, sia perquanto riguarda lhw che il sw. Questo perch ogni appli-cazione che deve girare sullambiente di produzione vieneprima installata nellambiente di staging, verificando chenon ci siano conflitti con le altre applicazioni e che la mac-

china risponda come atteso. Solo dopo la certificazionenello staging, il software viene installato in produzione.Date le nostre esigenze, lambiente di staging non tut-

tavia ancora necessario e quindi non labbiamo implemen-tato.

Lambiente di produzione invece costituito da macchi-ne in hosting, cos da non avere in casa le problematichedi manutenzione legate alla gestione dei server virtual-mente 24x7.

Per quanto riguarda il sistema operativo dei server abbia-mo scelto (e in questo caso il costo non stato il fattoredeterminante) di usare Linux. La macchina di QA inve-ce pensata per essere formattata in qualunque momento ericonfigurata con uno specifico sistema, nellottica di ese-

guire il testing su una qualsiasi piattaforma supportata.

Editor e IDE

Non c amico pi fedele di uno sviluppatore che il suoeditor o IDE (in realt, per quanto mi riguarda ce n uno

ancora pi importante che per lavora dietro le quinte: ilversion control system). Siccome ogni sviluppatore piproduttivo con leditor che preferisce, allinterno del teamnon si imposto nessun editor particolare. Ovviamente,anche in questo caso ci si pu dotare di ottimi strumentishareware, tra cui, per quanto riguarda gli editor, molto uti-

lizzati sono UltraEdit [1] e TextPad [2]. Io sono particolar-mente affezionato a TextPad, mentre Fabione, colonnaportante del reparto tecnico, usa UltraEdit. In aggiunta aTextPad, il mio IDE preferito NetBeans [3], completa-mente free e open source e che viene addirittura fornito inbundle con la JDK 1.4.2.

Sebbene la scelta delleditor o IDE sia soggettiva, la scel-ta dello stile di programmazione non lo del tutto (so chequesto far drizzare un po le orecchie, ma vedremo piavanti nellarticolo perch) ed importante che lo stru-mento selezionato abbia alcune funzionalit di base, in par-ticolare legate alla formattazione e al formato del testo:possibilit di gestire i diversi tipi di a capo e diversi tipidi spaziatura (solo spazi, solo tab, dimensione dei tab, con-

versione di tab in spazi).

Version Control System

Il version control system un altro fido amico del pro-grammatore. costituito da un repository centrale di tuttii file relativi ai progetti con lo scopo di tenerne sotto con-trollo le varie versioni. Quando un file viene inserito perla prima volta nel repository, ne costituisce la versioneiniziale. Un file nel repository pu essere estratto e par-cheggiato sul proprio ambiente di sviluppo locale conuna operazione di check out. Il file cos ottenuto edita-bile dal programmatore che, a modifiche ultimate, pureinserirlo nel repository con una operazione detta dicheck in. In questo caso, il version control system, noninserir in repository lintero file, ma le sole differenze trala nuova versione e quella precedentemente memorizzata.Inoltre, al nuovo file viene associato un nuovo numero diversione (es: da 1.1 a 1.2). Luso di un version controlsystem apporta notevoli vantaggi in un ambiente di svi-luppo multiutente:

pi sviluppatori possono lavorare contemporaneamen-te sulla stessa base di codice;

si ha sempre un repository centrale del codice, cosa chene rende pi semplice la gestione e il backup;

in qualsiasi momento possibile recuperare una prece-dente versione di un file o di un intero build.

Ci sono molti software di version control, anche free oopen source. Uno dei pi utilizzati e affidabili proprio unsoftware open source dal nome CVS [4] (concurrent ver-sion system), che per altro preinstallato e pronto allusocon Linux (selezionando i componenti di supporto allo svi-luppo). CVS unapplicazione client/server, costituito cioda una componente server, da installare su una macchinacondivisa, e una componente client da installare sul pro-prio pc di sviluppo.

Client e server comunicano via rsh (remote shell), ciolanciando lesecuzione dei comandi di CVS sul server dallapostazione client remota. La dotazione minimale di CVSprevede una serie di comandi da eseguire da una shell, di-

sponibili per moltissime piattaforme. Per esempio, cvs ci serve per fare il check in di un file, mentre cvsco usato per fare il check out. anche possi-bile lavorare a livello di directory e ricorsivamente, cosche una stessa operazione sia applicata a un intero albero

FIGURA 1 WinCVS


5/8



di directory. Considero il fatto di poter effettuare tutte leoperazioni di gestione dei file via linea di comando un pre-gio e non un difetto di CVS. Infatti, questo consente diautomatizzare le procedure di gestione con dei sempliciscript di shell che possono essere eseguiti in modo nonsupervisionato e magari schedulati regolarmente.

Una diatriba sempre viva nel contesto dei sistemi di ver-sioning legata alla possibilit di fare il check out esclusi-vo di un file da parte di uno sviluppatore. In questo caso,finch la persona che ha fatto il check out non fa il checkin della nuova versione o non rimuove deliberatamente illock, il file non pu essere modificato e soprattutto inseri-to nel repository da altri. il caso di Microsoft Source Safe,per citare un version control system sicuramente molto dif-fuso. CVS invece non ha funzionalit di check out esclusi-vo e non per limitazione del software, ma per scelta. InfattiCVS adotta una strategia che in campo database si defini-rebbe ottimistica: pi persone possono lavorare sullo stessofile contemporaneamente effettuando un merge delle diffe-renti versioni quando necessario a check in time.

Per spiegare meglio questa problematica, si supponga chedue sviluppatori facciano il check out dello stesso file, unfi-le.txt ver. 1.3, la mattina arrivati in ufficio. Entrambi lavo-rano sul file e quando hanno terminato ne fanno il checkin. Ovviamente uno dei due lo far prima dellaltro, nelqual caso sar un normale check in che porta la versionedel file nel repository a 1.4. Quando il secondo program-matore fa il check in della propria versione, ecco che sorgeun conflitto: infatti si sta cercando di inserire nel reposi-tory una nuova versione di unfile.txt:1.3, ma nel repository gi presente unfile.txt:1.4! CVS tenta quindi un merge,ossia compara le differenti versioni e tenta di applicare leopportune differenze per ottenere alla fine unfile.txt:1.5. Avolte per il merge non possibile, in quanto entrambi gliutenti hanno modificato le stesse parti del file; in questocaso necessario lintervento del programmatore che deveispezionare il risultato del merge e applicare le opportunecorrezioni.

Questa strategia ottimistica perch presuppone che lesituazioni di conflitto siano poco probabili, cosa abbastan-za sensata perch gli sviluppatori tendono a lavorare suunit di lavoro differenti. Ma soprattutto non si hannotutti quei conflitti originati dal semplice fatto che si effet-tutato un check out esclusivo dimenticandosi di rimuove-re il lock il giorno prima di partire per le ferie.Personalmente preferisco lapproccio di CVS, anche consi-derato il fatto che una minimale disciplina di sviluppo (che

vedremo fra poco) minimizza il problema dei merge.Unaltra importante funzionalit di CVS il taggingdelleversioni: possibile assegnare a singole versioni di fileallinterno di un progetto una stessa etichetta, cos da crea-re un legame tra essi. Per esempio si possono contrassegna-re tutti i file (e le specifiche versioni) che costituiscono ilbuild quotidiano del progetto. Si supponga che il progettoMioProgetto sia costituito dai seguenti file:

src/java/MioFile1.java src/java/MioFile2.java readme.txt

La versione iniziale del progetto potrebbe essere cos

costituita:

src/java/MioFile1.java:1.1 src/java/MioFile2.java:1.1 readme.txt:1.1

Possiamo quindi creare un tag mio_progetto_1_0 cherappresenta MioProgetto ver 1.0:

src/java/MioFile1.java:1.1 mio_progetto_1_0 src/java/MioFile2.java:1.1 mio_progetto_1_0 readme.txt:1.1 mio_progetto_1_0

Tuttavia, lo sviluppo del progetto continua finch final-mente si giunge alla release 2.0. Supponiamo che lo statodel repository alla versione 2.0 sia:

src/java/MioFile1.java:1.1 mio_progetto_1_0 src/java/MioFile2.java:1.8 src/java/MioFile3.java:1.4 readme.txt:1.2

Si noti che MioFile1.java rimasto invariato e possiedequindi il tag precedentemente associatogli. Gli altri filesono stati modificati o sono nuovi e, quindi, in quella par-ticolare versione non hanno nessun tag.

Creiamo quindi il tag mio_progetto_2_0, ottenendo ilrepository:

src/java/MioFile1.java:1.1 mio_progetto_1_0, mio_progetto_2_0

src/java/MioFile2.java:1.8 - mio_progetto_2_0 src/java/MioFile3.java:1.4 - mio_progetto_2_0 readme.txt:1.2 - mio_progetto_2_0

Linterpretazione abbastanza intuitiva: MioFile:1.1appartiene a entrambe le release di MioProgetto, mentre,nel caso per esempio di MioFile2.java, MioProgetto v1.0contiene MioFile2.java:1.1, mentre MioProgetto v2.0 con-tiene MioFile2.java:1.8.

Naturalmente i comandi di CVS permettono di lavoraresu una specifica revisione di un file, specificandone la ver-sione, la data di check in o un tag. Dato lo spazio limitatodellarticolo, non possibile approfondire ulteriormenteluso di CVS in queste pagine; invito chi fosse interessatoa consultare la documentazione disponibile sul sito edeventualmente a installarlo e toccare con mano.

Ho accennato prima al fatto che CVS usa uninterfacciaa linea di comando per eseguire i comandi di check in,check out, ecc.

Fortunatamente, non la sola interfaccia disponibile, mace n una completamente grafica per gli ambientiWindows. Si tratta di WinCVS [5], anchessa frutto di un

progetto open source ospitato su SourceForge [6]. InFigura 1 possibile vederne uno screenshot.Un altro utile tool riguardante CVS che abbiamo instal-

lato sul web server interno ViewCVS [7]. Installato comeCGI, permette di navigare il repository CVS via web conun normale browser. Lo trovo molto utile per avere imme-diato accesso alle varie versioni, tag e contenuti dei sor-genti. ovviamente un progetto open source utilizzatodallo stesso SourceForge (Figura 2).

Bug tracking systemPer quanto bravi possano essere i programmatori, non

riusciranno mai a sviluppare software privo di bachi, anchesolo per il fatto che a volte il confine tra baco e diversa fun-

zionalit non cos netto. sempre bene diffidare di chiritiene di potersi ricordare i vari malfunzionamenti riscon-trati e quindi sistemarli a memoria. Uno strumento permantenere un database dei bachi fondamentale ancheper piccoli progetti e anche quando c un solo sviluppato-


6/8


FOCUS

re. Non solo utile per ricordare i malfunzionamenti dasistemare, ma anche per poter avere quando serve unavisione di insieme, assegnare i task agli sviluppatori, dare lagiusta priorit ai problemi. assolutamente controprodu-cente sistemare un baco, anche complesso, che solo il 10%degli utenti riscontra quando una semplice, ma fastidiosaanomalia si manifesta a tutti gli utenti appena avviato ilprogramma. Affidarsi alla sola memoria quantomenorischioso.

Per questo importante avere un sistema di bug tracking.Esso pu essere molto semplice, come un normale foglioExcel, o molto complesso con funzionalit di changemanagement e reporting. Nella scelta dello strumento piadatto alla propria soluzione, un fattore importante da con-siderare che sia facile e immediato da utilizzare per gli svi-luppatori. Infatti, un meccanismo troppo complesso etedioso tende a far s che gli sviluppatori lo usino contro-voglia e quando costretti, minimizzando i benefici che nederivano. I programmatori devono invece vederlo comeulteriore amico.

Poteva non esserci un software open source di bug trac-king? Ovviamente no! Anzi, ce ne sono diversi, pi omeno complessi, alcuni con integrate funzionalit di pro-ject management e quasi tutti utilizzabili via web. Tuttaviadopo qualche ricerca, sono giunto alla conclusione che ilprodotto pi adatto per il nostro ambiente di sviluppo siaBugzilla [8]. molto completo, ma al contempo facile da

usare; accessibile via web e salva i dati in un databaseMySQL [9] cos che se in futuro ci sar la necessit di faredel reporting sar sempre possibile interrogare il db.Lunico punto a sfavore di Bugzilla linstallazione: sebbe-ne sia piuttosto semplice, ho avuto qualche problema neltrovare e scaricare tutti i moduli Perl necessari. Al momen-to comunque funziona egregiamente e non mi ha dato nes-sun tipo di problema.

DatabaseIn ogni ambiente di sviluppo non si pu fare a meno di

un database. Non tanto per esigenze dellambiente in s(anche se software come Bugzilla in realt insistono su undatabase relazionale), quanto per il fatto che le applicazio-

ni che si vanno a sviluppare hanno generalmente bisognodi una base dati.

Anche in questo caso la scelta di Linux come piattafor-ma di sviluppo si rivelata molto comoda. Infatti, nelladistribuzione standard sono gi presenti i database

PostgreSQL [10] e MySQL [11]. stato sufficiente atti-varli e creare i database e gli schemi necessari per essereoperativi.

MySQL senzaltro uno dei pi conosciuti, perch uti-lizzato in moltissime applicazioni web. un database opensource che tuttavia, fino a poco tempo fa, soffriva di note-

voli mancanze dal punto di vista relazionale (per esempiole transazioni) che lo rendevano utilizzabile soprattutto perbasi di dati in sola lettura. Per le esigenze di molti siti webquesto approccio pi che sufficiente e consente una mag-giore velocit di esecuzione, grande punto di forza diMySQL.

Dalle ultime notizie reperibili sul sito, sembra che le ulti-me versioni di MySQL utilizzino un nuovo motore relazio-nale, chiamato InnoDB, avente tutte le caratteristicherichieste a un RDBS che si rispetti. In pi, promettono pre-stazioni veramente eccezionali, anche comparate a prodot-ti commerciali molto pi conosciuti.

PostgreSQL un altro RDBMS open source. pi anzia-no e maturo di MySQL e ha da sempre tutti i costrutti

transazionali e relazionali che portano a considerarlo unottimo e robusto DBMS. Le prestazioni sono in alcuni casiinferiori a MySQL, ma il fatto di esistere da parecchiotempo d maggiori garanzie di affidabilit, cosa che consi-dero fondamentale per applicazioni pi critiche (come ilportale). La decisione che ho preso quindi di utilizzareMySQL quando esplicitamente richiesto, ma PostgreSQLcome piattaforma standard per applicazioni critiche.Questo con il proposito per di fare una pi approfonditaanalisi di prestazioni comparando i database su unapplica-zione reale.

Application ServerIl software che sviluppiamo principalmente costituito

da un middleware eseguito lato server e da un portale web,cio il tipo di software che meglio si adatta ad essere ese-guito allinterno di un application server. In questo ambitola piattaforma scelta basata sullo standard J2EE, per moti-vazioni sia tecnologie sia di know-how. Anche nel campodegli application server J2EE le possibilit di scelta sononumerose, sia nel campo dellopen source, sia in quellocommerciale. Inoltre, anche molti ambienti commercialipermettono luso free dei loro software per scopo di svilup-po. Tuttavia, avendo anche la necessit di distribuire ilnostro prodotto in una versione a basso costo e soprattuttofacendo un bundle unico con lapplication server per chinon ne avesse gi uno in casa, la scelta caduta su un pro-

dotto open source: JBoss. Questultimo un prodotto tec-nologicamente avanzato e molto semplice da installare eusare, utilizzato da milioni di utenti nel mondo: insomma,risponde adeguatamente a tutte le nostre esigenze.

Project buildHo pi volte accennato al build o al processo di build.

Con la parola build, intendo una specifica versione com-pleta del progetto. Questo significa preparare tutto quelloche serve per creare una versione del prodotto software chepu essere distribuita o installata sul sistema finale. Il pro-cesso per arrivare a tale risultato per un progetto non bana-le, generalmente costituito da diversi passi, che vannodalla compilazione dei sorgenti alla generazione della

documentazione, fino allimpacchettamento di tutto in unfile distribuibile.

Nulla vieta che alcuni o tutti questi passi possano essereeseguiti manualmente ricordandoseli a memoria; ma statesicuri che se anche un solo passo richiede lintervento

FIGURA 2 CVSWeb


7/8



umano, ne rimpiangerete lesistenza la prima volta in cuidovrete produrre un hot fix che deve andare in produzioneentro 15 minuti. Inizierete a cercare il foglio dove avetescritto le istruzioni (e gi questo potrebbe essere un ostaco-lo!) e a digitare i comandi uno a uno, sbagliandone il 90%e senza avere la certezza che tutto sia corretto.

Ritengo quindi fondamentale avere un processo di buildeseguibile senza lintervento di un operatore, cos che possaessere completamente automatizzato ed eventualmenteanche schedulato. Non raro infatti che per un progetto sucui lavorano pi persone si scheduli un build notturno chefaccia un check out completo dellultima versione del pro-getto dal CVS e produca il file di distribuzione o addirittu-ra faccia il deployment direttamente sullambiente di svi-luppo. In questo modo, la mattina seguente gli sviluppato-ri potranno operare con lultima versione completa delprogetto.

Un processo di questo tipo comporta unulteriore atten-zione da parte degli sviluppatori: tutto ci che inseriscononel repository del CVS non deve interrompere in alcun

caso la procedura di build. Torneremo su questo aspettoquando parleremo di processo di sviluppo.

Una considerazione da fare in questa area riguarda gliambienti di sviluppo. Infatti, per quanto ricchi di funzio-nalit di project building, generalmente non fornisconomai uninterfaccia anche a linea di comando, che possa peresempio essere utilizzata in uno script. Per questa ragionenon ritengo questi strumenti adeguati per il processo dibuild: essi richiedono sempre che uno sviluppatore premail preposto bottone o selezioni la necessaria voce di menu,oltre che essere fortemente focalizzati ai semplici sorgenti.

Uno strumento che trovo molto utile per risolvere buonaparte di questi problemi Ant [12]. Come gi descritto inun precedente numero di Computer Programming, Ant un tool di build basato su Java estremamente flessibile epotente, con una serie di funzionalit di base che copronola stragrande maggioranza delle esigenze di build, anche diprogetti complessi. Pu inoltre essere esteso con dei taskcustom, sviluppati appositamente per una particolare esi-genza; per esempio, un custom task da noi realizzato ci con-sente di automatizzare il processo di test di protocollo delnostro server SyncML.

Luso di Ant poi coadiuvato da uno o pi script di shellche permettono di assemblare facilmente a un pi altolivello lesecuzione di pi task del processo di build.

Backup

Nel campo dello sviluppo software, eseguire un periodi-co backup dei dati equivale a salvaguardare la quasi totali-t di ci che viene prodotto ed quindi unattivit di vita-le importanza. Nel nostro caso, un ruolo centrale rico-perto dal file server, che abbiamo appositamente configu-rato con due dischi uguali ma fisicamente distinti, cos chein caso di crash di un disco sia facilmente possibile rimet-tere in piedi il sistema con il secondo. Allo stesso tempo ilsecondo disco viene utilizzato anche come unit di backupdove ogni notte viene fatto un dump dei file system di svi-luppo.

Settimanalmente poi, un dump viene riportato diretta-mente su tape, cos da averne una copia su un dispositivoasportabile da conservare in luogo diverso dal server. Il

dump e leventuale restore vengono eseguiti con gli omo-nimi comandi di Linux.

Per esigenze pi complesse val la pena di citare Amanda[13], un software di backup client server molto utilizzato eanchesso open source.

Processo di sviluppoIn questa sezione tratter alcune regole di comporta-

mento che bene introdurre nel team di sviluppo al fine dilavorare al meglio con gli strumenti presentati. opportu-no comunque sottolineare che questo tipo di regole deveessere condiviso e concordato con il team di sviluppo e

non essere imposto.Una procedura di particolare importanza quella cheriguarda il processo di sviluppo e di build in presenza di unagestione centralizzata dei progetti tramite un version con-trol system. Il presupposto da cui partire che in ognimomento lo stato di un build sar diverso dallimmagineche si ha in locale sulla propria macchina di sviluppo.Questo perch pi sviluppatori fanno il check in del pro-prio lavoro in momenti diversi. quindi importante cheognuno riporti le proprie modifiche appena possibile inCVS e faccia un nuovo check out di tutto il progetto ten-denzialmente ogni mattina prima di iniziare il lavoro.Partendo quindi da una situazione stabile, ogni singolo svi-luppatore esegue le proprie modifiche e finita ununit di

lavoro, ne fa il check in. Con finita ununit di lavoro siintende terminato lo sviluppo di una funzionalit, la corre-zione di un baco, la modifica di un file di testo, ecc., essen-do comunque sicuri di almeno due cose:

1) che dopo il check in, il build di un check out completodel progetto vada a termine senza errori;

2) che le proprie modifiche raggiungano lo scopo per lequali sono state introdotte e non entrino in conflittocon altre modifiche fatte da altri.

Il primo punto di particolare importanza perch avereun build rotto significa che la mattina successiva nessu-no potr eseguire la nuova versione dellapplicazione primache il build venga sistemato. Quando il team inizia a esse-re composto da tre o quattro unit, bene identificare unbuild master che si assicuri che tutte le operazioni riguar-danti il processo di build siano state effettivamente attuatecon successo. Una strategia che si pu adottare per disin-centivare in modo simpatico il check in di modifiche checorrompano il build quella di investire del ruolo di buildmaster proprio il responsabile delle modifiche che hannocorrotto lultimo build.

Venendo al caso particolare delluso di CVS, impor-tante introdurre unaltra buona abitudine. Prima di fare ilcheck in delle proprie modifiche bene fare un queryupdate del build. Con la funzionalit di query update possibile verificare lo stato di tutti i file del progetto, evi-denziando quelli modificati localmente, quelli invece

modificati nel repository centrale e quelli eventualmentemodificati sia centralmente sia localmente. Quesultimocaso rappresenta uno dei conflitti di cui abbiamo parlatoprecedentemente. quindi necessario che lo sviluppatoreesegua prima un update della nuova versione del file e

Ant un tool di buildbasato su Java

estremamente flessibile

e potente


8/8


FOCUS

quindi applichi le proprie modifiche su questultima.Lasciare questo compito a CVS non certamente unabest practice e comunque non risolutiva in tutti i casi(in alcuni casi CVS richiede comunque linterventoumano). Si tenga comunque presente che nulla pi effi-cace che il parlarsi allinterno del team, chiedendo luno

allaltro se si sono fatti nuovi check in o modifiche signifi-cative. Ci pu sembrare una banalit, ma ho lavorato permesi in un team di sviluppo piuttosto numeroso dove unodei problemi principali legati alluso di un version controlsystem era proprio la mancata comunicazione tra i membridel gruppo di lavoro.

Una seconda buona abitudine quella di avere sempreuna lista dei task da eseguire. Lo scopo di questa lista non di tenere traccia di chi fa cosa e in quanto tempo, ma diavere sempre sottocchio la lista di cose da fare e che sisono fatte con i relativi tempi stimati e tempi di realizza-zione. Un foglio elettronico pi che sufficiente, bastainserire le seguenti colonne: task e subtask, tempo stimato,tempo passato (ad oggi), tempo impiegato (a concludere il

task), data inizio, data fine. Lo scopo di mettere date etempi non tanto quello di tener traccia della produttivi-t degli sviluppatori, quanto quello di esercitarsi a daredelle stime il pi possibile precise dei tempi di realizzazio-ne dei task. Il fatto di avere sottocchio la storia preceden-te consente di avere un riferimento nel fare le nuove stime.

Infine, unultima linea guida per quanto riguarda i bachi.Abbiamo gi detto della fondamentale importanza delsistema di back tracking; questo torna molto utile nel pro-cesso di sviluppo perch in molti casi preferibile risolve-re prima i bachi e poi implementare nuove funzionalit.Infatti c la tendenza a considerare il bug fixing non com-preso nei task e nelle deadline da completare e raggiunge-re (anche perch la segnalazione avviene in una fase avan-zata dello sviluppo del software). Soprattutto in caso di sca-denze molto ravvicinate e sotto stress c quindi la tenden-za a scrivere pessimo codice tanto per non fallire la sca-denza, con la conseguenza di trasformare semplicementeun task nella tasklist in un baco che verr comunicato suc-cessivamente. Inoltre sviluppare nuovo codice su una basedi codice malfunzionante non pu che aumentare la fragi-lit e linstabilit dellintero build. Senza contare cheaggiustare un bug sfuggito nello sviluppo di qualche giornoaddietro richiede meno tempo che non sistemarlo dopoalcuni mesi.

Per queste ragioni una metodologia che pu essere adot-tata quella dello zero defects, non intesa come lo svi-

luppo di codice senza bachi, ma come dare massima priori-t alla risoluzione dei bachi, pi ancora che allo sviluppo dinuove funzionalit.

Standard di codifica

Unaltra disciplina che ritengo importante quella diaderire a standard di codifica. Sono convinto che ogniteam di lavoro debba elaborare degli standard di codificache ogni sviluppatore deve poi seguire nella stesura delcodice. Ancora una volta lo scopo non quello di imporreun inutile e fastidioso formalismo, ma quello di prendereatto che lo sviluppo del software in un ambiente multisvi-luppatore deve adottare delle semplici regole che consen-tano il pi possibile a tutti i membri del gruppo di essere

subito produttivi al 100% anche quando lavorano su codi-ce sviluppato da altri. Quante volte vi capitato di aprireun file e non vederlo correttamente semplicemente perch stata utilizzata una tabulazione diversa da quella delvostro editor? In casi semplici molti IDE vengono in aiuto

con una riformattazione automatica, ma poi sar lo svilup-patore originario a non vedere pi il file in modo corretto.Spesso si tratta di piccole cose, ma che infastidisconomolto i membri del team. Il principio che quanto pi silascia libert di scelta dei tool di sviluppo, tanto pi impor-tante la condivisione degli standard di codifica. In pi, la

stesura di specifiche di codifica consente di condensare inpoche regole lesperienza di buona programmazione deglisviluppatori pi anziani a tutto beneficio dei nuovi arriva-ti.

Gli standard di codifica possono descrivere moltissimiaspetti della programmazione, dalla stesura dei file sorgen-te, alluso di particolari costrutti di programmazione, a con-venzioni sui nomi di variabili e procedure, ecc.: definisco-no quindi uno stile di programmazione che diventer lostile del team. Ecco alcuni punti che possono essere tratta-ti:

Creazione dei file sorgente (intestazione, struttura didirectory, commenti iniziali, ecc.).

Convenzioni sui nomi per: Classi Metodi Variabili Costanti Commenti Stile di scrittura Lunghezza delle linee Spaziatura e tabulazioni Indentatura Uso delle parentesi

Logging Gestione delle condizioni di errore

ConclusioniIn questo articolo si visto un possibile modo di orga-

nizzare un ambiente di sviluppo in termini di sistemi e soft-ware necessari. Si mostrato come ci sia possibile utiliz-zando software open source e quindi a costo zero.

Si noti che non stata effettuata una specifica ricerca disoftware free, ma semplicemente i tool pi comunementeutilizzati sono anche disponibili a tutti senza nessun costo.Il vantaggio di poter trovare unenorme comunit di uten-ti che ha gi affrontato e risolto le stesse problematiche, simanifesta in unestrema facilit di settaggio dei vari soft-ware e di risoluzione dei problemi. Inoltre, ladozione di unsistema operativo come Linux consente di avere disponibi-

le in ununica installazione gran parte di ci di cui si habisogno.

RIFERIMENTI

[1] http://www.ultraedit.com[2] http://www.textpad.com[3] http://www.netbeans.org[4] http://www.cvshome.org[5] http://www.wincvs.org[6] http://sourceforge.net[7] http://viewcvs.sourceforge.net[8] http://www.bugzilla.org[9] http://www.mysql.com[10] http://www.postgresql.org[11] http://www.mysql.com[12] http://ant.apache.org[13] http://www.amanda.org

Allestire un ambiente di sviluppo

Documents

Transcript of Allestire un ambiente di sviluppo