Infrastruttura di Supporto allo Sviluppo Software nell`INFN

2
Infrastruttura di Supporto allo
Sviluppo Software nell'INFN
3
Proposta di Progetto
4
3 luglio 2012
1
Contenuto
1. Introduzione......................................................................................................................................1
2. Descrizione generale.........................................................................................................................1
3. Funzioni............................................................................................................................................2
3.1. Gestione di progetto.......................................................................................................................2
3.2. Controllo di versione.....................................................................................................................3
3.3. Controllo di qualità........................................................................................................................3
3.4. Continuous integration..................................................................................................................4
3.5. Disponibilità di piattaforme di sviluppo........................................................................................4
3.6. Efficienza.......................................................................................................................................4
3.7. Formazione....................................................................................................................................4
3.8. Technology tracking......................................................................................................................5
4. Piano esecutivo.................................................................................................................................5
5. Valutazione dei costi.........................................................................................................................5
5
1. Introduzione
6
7
8
9
10
11
12
13
14
15
Il successo di un progetto scientifico dipende da molti fattori. Tra questi, la capacità di raccogliere e
successivamente processare grandi quantità di dati ha assunto negli anni un ruolo sempre più
rilevante. Nonostante il progresso tecnologico abbia consentito di fornire processori, memorie,
dischi e reti di comunicazione sempre più veloci e affidabili, il costo del fattore calcolo rimane
rilevante. Inoltre, l'esaurimento di linee di sviluppo tecnologico che avevano consentito quel
progresso – basti ricordare il raggiunto limite della frequenza di clock nei processori, il cui aumento
costante negli anni aveva fino ad ora garantito un corrispondente aumento di prestazioni senza di
fatto ulteriori sforzi – richiede ora invece di dedicare maggiore attenzione alla metodologia di
sviluppo del software. Gran parte dell'onere di sfruttare appieno le potenzialità offerte dall'hardware
è stato idealmente spostato dall'ingegnere elettronico all'ingegnere del software.
16
17
18
Questo progetto si propone dunque di creare una infrastruttura materiale e di conoscenze che possa
supportare i progetti di sviluppo software che avvengono nell'INFN, per aiutarli a produrre software
di qualità a costi ridotti e rispettando le scadenze.
19
2. Descrizione generale
20
21
22
23
24
25
L'infrastruttura oggetto di questa proposta è pensata per integrare diverse funzioni, ognuna delle
quali concorre a raggiungere l'obiettivo primario di produrre software di crescente qualità,
riducendone i costi e rispettando le scadenze. Il concetto di qualità è da intendersi in senso ampio e
comprende caratteristiche quali la bassa incidenza di errori, l'efficienza di esecuzione, la
manutenibilità, la portabilità a nuove piattaforme. Parimenti, il concetto di costo copre diversi
aspetti, quali le persone dedicate allo sviluppo e il tempo necessario non solo allo sviluppo, ma
1
Infrastruttura di Supporto allo Sviluppo Software nell'INFN
1
anche al mantenimento in esercizio del software.
2
All'obiettivo primario si affiancano alcuni obiettivi secondari:
3
4
5
6
•
Lo sviluppo del software deve essere un'attività piacevole e non, come spesso accade, una
fonte significativa di stress per le persone coinvolte. In particolare per il ricercatore in fisica
il software deve essere solo lo strumento per raggiungere il fine della sua ricerca e non
invece impegnare, come spesso accade, una parte eccessiva del suo tempo.
7
8
9
10
•
Le conoscenze accumulate nella implementazione, nel mantenimento e nell'uso
dell'infrastruttura possono essere condivise all'interno dell'ente. Inoltre la maturazione di una
comunità interessata al tema dello sviluppo software creerebbe le condizioni per un'attività
sistematica di formazione sia per il personale esistente sia per il personale futuro.
11
12
13
•
La presenza di esperienza consolidata sul tema dello sviluppo software rappresenterebbe
un'occasione importante di contatto con altri enti e con l'industria e potrebbe rientrare nel
portafoglio di competenze che l'INFN mette a disposizione per il trasferimento tecnologico.
14
15
•
Un'attività consolidata di software engineering agevolerebbe la collaborazione con i
dipartimenti di informatica, con beneficio reciproco.
16
Le funzioni che l'infrastruttura oggetto di questo progetto identifica sono:
17
•
gestione di un progetto software
18
•
controllo di versione
19
•
controllo di qualità
20
•
continuous integration
21
•
disponibilità di piattaforme di sviluppo
22
•
efficienza e ottimizzazione della performance
23
•
formazione
24
•
technology tracking
25
26
27
Le funzioni elencate sono presentate in dettaglio nelle sezioni seguenti. Per ognuna viene indicata
anche la modalità di implementazione, eventualmente specificando quali strumenti potrebbero
dimostrarsi utili.
28
Infine viene stimato il costo del progetto sia in termini di personale sia in termini finanziari.
29
3. Funzioni
30
3.1. Gestione di progetto
31
32
33
34
35
36
37
Ogni progetto software che vada al di là di un esercizio di durata temporanea svolto da una sola
persona beneficia di un sistema di gestione di progetto. Il beneficio aumenta con l'aumentare della
complessità del progetto, della sua durata prevista, del numero di persone coinvolte nello sviluppo,
del numero di utilizzatori, fino a diventare un requisito essenziale. La principale funzionalità che un
sistema di gestione di progetto offre è la possibilità di tracciare adeguatamente le modifiche
applicate al codice, siano esse correzioni di errori o implementazione di nuove funzionalità, le
richieste di supporto da parte degli utilizzatori e tutte le altre azioni necessarie a tenere sotto
2
Infrastruttura di Supporto allo Sviluppo Software nell'INFN
1
2
controllo lo sviluppo (ad es. la gestione delle release, la raccolta delle richieste di miglioramenti o la
preparazione di report periodici). Una entità tracciata in un project tracker viene detta issue.
3
4
L'INFN si è già dotato di uno strumento adeguato di project tracking: JIRA1, disponibile su
https://issues.infn.it/.
5
3.2. Controllo di versione
6
7
8
9
10
11
12
Un sistema di controllo di versione (Version Control System, VCS) consente di registrare in modo
permanente tutte le modifiche applicate a un codice sorgente (da intendersi in senso lato e
comprendente ad esempio la documentazione o le istruzioni per compilare e impacchettare il
codice). Se fatto in modo sistematico e disciplinato, ciò consente ad esempio di mantenere in vita
più versioni dello stesso prodotto oppure a più persone di sviluppare in parallelo senza timore di
conflitti o ancora semplicemente di poter annullare in modo sicuro modifiche che si sono rivelate
errate.
13
14
15
Le modifiche al codice gestite dal VCS si possono associare agli issue mantenuti nel project tracker,
consentendo una agevole navigazione tra i due e permettendo il controllo dell'intera filiera dal
requirement alla modifica nel codice alla release che la comprende e viceversa.
16
17
18
Esistono molti VCS a disposizione. Ultimamente si stanno imponendo dei sistemi cosiddetti
distribuiti (DVCS), tra i quali i più diffusi sono git2 e mercurial3. Tra quelli tradizionali
(centralizzati) il più diffuso è subversion4. E' previsto che tutti siano disponibili su code.infn.it.
19
20
21
22
23
Degne di nota sono anche soluzioni cosiddette hosted, in cui un provider offre spazio disco e
applicazioni web (quali wiki, tracker, code review, ecc.) per gestire dei progetti software. Ne sono
esempio github5 e bitbucket6. Tali soluzioni potrebbero essere adottate per piccoli progetti di
carattere personale oppure, all'estremo oppposto, per grossi progetti open-source che vedono il
coinvolgimento di un numero rilevante di persone esterne all'INFN.
24
3.3. Controllo di qualità
25
26
27
28
29
30
La qualità di un prodotto software è un concetto che copre diversi aspetti, quali affidabilità,
efficienza, sicurezza, manutenibilità. Esistono metodologie consolidate, che non sono altro che
insiemi di raccomandazioni, che aiutano gli sviluppatori a raggiungere livelli accettabili di qualità,
dove “accettabile” dipende dal contesto specifico del prodotto in questione. Un prodotto sviluppato
secondo tali metodologie permette anche di tenere sotto controllo il costo e il raggiungimento degli
obiettivi secondo le scadenze pianificate.
31
32
33
Lo scopo di questa funzione è quindi soprattutto di rendere gli sviluppatori consapevoli delle
metodologie esistenti, ad esempio sotto forma di documentazione, di formazione e di scambio di
esperienze.
34
35
Esiste tuttavia la possibilità di avere accesso anche a strumenti che aiutano a raggiungere gli
obiettivi di qualità prefissati. Tra questi, sono stati recentemente acquisiti al CNAF due prodotti di
1
2
3
4
5
6
https://www.atlassian.com/software/jira
http://git-scm.com/
http://mercurial.selenic.com/
https://subversion.apache.org/
https://github.com/
https://bitbucket.org/
3
Infrastruttura di Supporto allo Sviluppo Software nell'INFN
1
analisi statica del codice: C/C++test7 e Jtest8, per codice scritto rispettivamente in C/C++ e in Java.
2
3.4. Continuous integration
3
4
5
6
7
8
9
Durante lo sviluppo del codice è importante verificare continuamente che le modifiche introdotte
non introducano situazioni di errore, sia in fase di build (compilazione, linking, ecc.) sia di
incompatibilità con altre componenti dello stesso sistema sia al run-time. Idealmente ogni nuova
modifica introdotta nel VCS dovrebbe causare un tentativo di build dell'intero sistema, seguito da
una serie di test di verifica. Questo approccio, conosciuto con il nome di Continuous Integration,
data la sua complessità, richiede l'assistenza di uno strumento adeguato. Uno tra i più noti di questi
strumenti è Jenkins9, di cui esiste già una certa esperienza nell'INFN.
10
3.5. Disponibilità di piattaforme di sviluppo
11
12
13
14
L'obiettivo di questa funzione è di rendere agevole per lo sviluppatore l'accesso a macchine
adeguate per l'attività di sviluppo, comprendendo in questa accezione tutte le fasi dello stesso, dalla
scrittura del codice, al build (magari su piattaforme diverse), alle varie fasi di test, alla
pre-produzione.
15
16
17
La fornitura delle macchine potrebbe essere implementata al di sopra di una infrastruttura di tipo
cloud (IaaS, PaaS, SaaS a seconda dei casi). Un candidato naturale per l'infrastruttura sottostante è
WNoDeS10, sviluppato dentro l'INFN, ma anche altre soluzioni sono possibili.
18
3.6. Efficienza
19
20
21
Date le dimensioni delle esigenze di calcolo di un tipico esperimento attuale, anche un minimo
miglioramento dell'efficienza del software equivale a risparmi significativi in termini di risorse di
calcolo, siano esse processori, memorie, storage, rete o anche semplicemente corrente elettrica.
22
23
24
25
26
27
28
29
30
Inoltre le problematiche relative al raggiungimento di limiti nella capacità di dissipazione di calore
nei microprocessori hanno causato un cambio di rotta nell'architettura degli stessi. Fino a qualche
anno fa infatti l'aumento delle prestazioni era ottenuto “semplicemente” aumentando la frequenza di
clock e migliorando il parallelismo delle istruzioni implementato a livello hardware, senza
richiedere di fatto alcuna modifica a livello di codice. Ora invece quell'approccio ha
sostanzialmente esaurito il suo contributo ed è stato sostituito da un aumento delle unità di calcolo
(core) disponibili sullo stesso processore. Questo però ha come conseguenza che lo sfruttamento
pieno dei diversi core debba essere affrontato a livello applicativo, con modifiche quindi
potenzialmente molto invasive al codice per renderlo parallelo.
31
32
33
Gli ambiti di ottimizzazione o di parallelismo possibili sono molteplici: modello di calcolo generale,
algoritmi e strutture dati, linguaggio di programmazione, opzioni di compilazione, tecniche
implementative.
34
35
36
37
Questa funzione si propone di offrire innanzitutto strumenti sia di profilazione dell'esecuzione per
individuare i punti in cui questa incontra i maggiori colli di bottiglia, risolvendo i quali si
potrebbero ottenere di conseguenza i maggiori benefici, sia per individuare parti di codice
potenzialmente parallelizzabili.
7
8
9
10
http://www.parasoft.com/jsp/products/cpptest.jsp?itemId=47
http://www.parasoft.com/jsp/products/jtest.jsp?itemId=14
http://jenkins-ci.org/
http://web.infn.it/wnodes/
4
Infrastruttura di Supporto allo Sviluppo Software nell'INFN
1
3.7. Formazione
2
3
4
5
6
7
Le funzioni illustrate fino ad ora hanno riguardato soprattutto aspetti materiali dell'infrastruttura
oggetto di questa proposta. Ma la loro disponibilità sarebbe di limitata utilità se essa non fosse
accompagnata da una adeguata capacità di formazione specifica sul loro utilizzo, ma anche, e forse
soprattutto, da un'ampia diffusione, tra gli addetti ai lavori, della cultura che la produzione di
software deve avvenire secondo criteri e raccomandazioni consolidati, che sono la migliore garanzia
per ottenere dei prodotti di qualità, a costi ridotti e rispettando le scadenze previste.
8
9
La condivisione di una infrastruttura comune inoltre facilita la condivisione di esperienze e
conoscenze tra i membri della comunità.
10
3.8. Technology tracking
11
12
13
14
15
L'evoluzione tecnologica tumultuosa degli ultimi anni (l'elevato parallelismo nei microprocessori e
l'esplosione dei servizi Grid/Cloud, solo per citarne due) richiede una costante attenzione alle novità
che appaiono o che appariranno a breve sul mercato. Quando queste hanno un potenziale impatto
sul software di un esperimento, è auspicabile che l'esposizione al nuovo prodotto avvenga il prima
possibile, così da anticipare le modifiche eventualmente necessarie al codice.
16
17
E' dunque importante dotarsi di un ambiente controllato in cui tali prodotti possano essere installati
e provati. Una opportunità di questo tipo è offerta dall'OpenLab11 del CNAF.
18
4. Piano esecutivo
19
20
La sfida principale nell'implementazione dell'infrastruttura descritta nelle sezioni precedenti sta
soprattutto nell'integrazione di tutti gli aspetti citati in un sistema unico e di facile utilizzo.
21
22
23
Fortunatamente non ci sono forti dipendenze tra le varie funzioni, per cui il lavoro può da un lato
procedere in parallelo, dall'altro non è necessario affrontare tutte le problematiche allo stesso tempo.
Questo permette tra l'altro di rendere il sistema stabile prima di passare al passo successivo.
24
25
26
27
Alcune funzioni sono certamente più importanti di altre ed è per questo motivo che la loro
implementazione è già in corso, a partire innanzitutto dalla funzione di gestione di progetti. JIRA
ospita infatti già diversi progetti legati al middleware di Grid e due progetti del Sistema Informativo
dell'INFN, uno dedicato allo sviluppo, l'altro al supporto.
28
29
30
31
Seguiranno le funzioni “Controllo di versione”, “Controllo di qualità” e “Continuous integration”,
per le quali esiste già una qualche esperienza nell'ente. E' prevedibile la necessità di un modesto
sviluppo per l'integrazione nel sistema complessivo dei componenti corrispondenti a queste
funzioni.
32
Discorso analogo vale per la funzione “Disponibilità di piattaforme di sviluppo”.
33
34
35
36
37
38
Le funzioni “Efficienza” e “Formazione” appaiono le più difficili da implementare, perché il loro
successo non richiede semplicemente l'acquisizione di uno strumento hardware o software e la sua
integrazione con altri strumenti. Richiede invece l'interazione con i potenziali beneficiari del
sistema allo scopo di incoraggiarli ad utilizzare il nuovo strumento a loro disposizione. Sarà quindi
necessario fin da subito presentare questa nuova infrastruttura nelle sedi opportune, preparare e
presentare materiale formativo e dare assistenza a chi intende farne uso.
11 http://vm-storage.cr.cnaf.infn.it/wiki/doku.php
5
Infrastruttura di Supporto allo Sviluppo Software nell'INFN
1
5. Valutazione dei costi
2
3
L'esecuzione del piano previsto nella sezione precedente prevede dei costi in termini sia finanziari
sia di personale.
4
I costi finanziari sono dati dall'acquisto di risorse hardware e software.
5
6
7
8
Per il software il costo è dato delle licenze e dipende dalla scelta degli strumenti utilizzati. Molti di
questi sono liberamente disponibili con licenze open-source; tra quelli citati rientrano in questa
categoria git, mercurial, subversion, Jenkins, WNoDeS. Altri invece sono a pagamento; tra quelli
citati rientrano in questa categoria JIRA, C/C++test, Jtest. im
9
Il costo di JIRA consiste in EUR 4000 all'anno per la manutenzione.
10
11
12
C/C++test è stato acquisito in via sperimentale con una licenza permanente a prezzi molto scontati
rispetto al listino. Lo stesso vale per Jtest, con la differenza che la licenza è annuale. Ulteriori costi
dipendono dalla valutazione degli strumenti che avverrà nel prossimo futuro.
13
14
15
Potrebbe essere utile acquisire strumenti di profilazione e supporto alla parallelizzazione del codice,
ad esempio da Intel, ma è prima necessario fare delle valutazioni. In ogni caso esistono degli
strumenti con licenza open-source che sono sicuramente sufficienti per partire.
16
17
18
19
20
21
Per l'hardware il costo è innanzitutto dato dall'acquisto dei server su cui girare le applicazioni
menzionate nelle sezioni precedenti e del corrispondente storage. Di quelle esplicitamente citate,
l'unico servizio mancante è Jenkins, per il quale si stima un costo limitato alle risorse necessarie per
espandere il pool dei servizi nazionali ospitati al CNAF e stimato in circa EUR 2000. Jenkins sfrutta
poi un pool di nodi su cui eseguire dei job di compilazione e test; è verosimile che questi nodi
possano derivare dalla dismissione di risorse del Tier1.
22
23
24
25
Un'altra componente di costo per l'hardware è dato dall'acquisizione delle macchine da includere nel
pool da cui un progetto può attingere per le proprie attività di sviluppo, secondo quanto previsto
nella Sezione 3.5. Anche in questo caso è verosimile che questi nodi possano venire dalla
dismissione di risorse dal Tier1, quindi di fatto senza costi ulteriori.
26
27
28
29
30
Per quel che riguarda il personale, l'intenzione è di costituire un gruppo di persone, tra tecnologi e
tecnici di varie sedi INFN, interessate al progetto e disposte a contribuire in vario modo
all'implementazione dell'infrastruttura. Una modalità potrebbe essere quella che ognuno si
specializzi e gestisca uno degli strumenti citati, affidandosi al Servizio Servizi Nazionali presso il
CNAF, che ospiterà materialmente le risorse, limitatamente agli aspetti sistemistici.
31
32
Tuttavia sarebbe utile se almeno inizialmente ci fosse una persona, ad esempio un assegnista di
ricerca, dedicata a tempo pieno al progetto.
33
34
35
36
37
Per il coordinamento delle persone coinvolte si farà ricorso prevalentemente a strumenti di
collaborazione remota. E' tuttavia realistico presumere che ci saranno alcune riunioni di persona,
così come va prevista la partecipazione a eventi in cui presentare i servizi offerti e il lavoro svolto.
Di conseguenza sarà necessario prevedere alcuni fondi per missioni nazionali, dell'ordine di 1000
Euro per ogni sede coinvolta.
38
6