Cosa sono e cosa servono i Build systems in informatica

Ecosistema Java/JVM

Il linguaggio Java è facile da comprendere e contiene poche astrazioni rispetto agli altri linguaggi di programmazione. La JVM (Java Virtual Machine) fornisce una base solida, portabile e ad alte prestazioni per l’esecuzione di Java o di altri linguaggi. Prendendole insieme, queste 2 tecnologie connesse forniscono una base su cui le aziende possono sentirsi sicure nella scelta di come impostare il proprio lavoro di sviluppo.

Sin dall’inizio di Java, è estremamente cresciuto un grande ecosistema di librerie e componenti di terze parti. Questo significa che un team di sviluppo pùo trarre enormi vantaggi dall’esistenza di driver e connettori per praticamente ogni tecnologia immaginabile, sia proprietaria che open source.

E’ questo fatto che è stato uno dei principali motori dell’adozione delle tecnologie Java da parte di aziende e grandi imprese. I team di sviluppo sono stati in grado di sbloccare il loro potenziale facendo uso di componenti e librerie preesistenti.

Piattaforma Java

Java non è però il solo linguaggio di programmazione che viene utilizzato per scrivere un comune programma; seguendo il paradigma “Write once, run anywhere” lo si è reso indipendente dalla piattaforma hardware specifica (platform independent), attraverso la quale si andrà ad eseguire il software sviluppato.

Per poter conseguire questo obiettivo è stata progettata la piattaforma Java (Java Platform) composta da 2 macro-componenti:

1. Java Virtual Machine: macchina astratta progettata per essere implementata sulla base dei processori e dei sistemi operativi attualmente esistenti.
2. Java Application Programming Interface (API): sono una serie di interfacce standard per lo sviluppo di applets e applicazioni a prescindere dal tipo di sistema operativo sottostante.

Un ambiente Java è formato da 2 fasi di sviluppo, quello a tempo di compilazione (compile-time environment) dove viene prodotto un particolare file che viene definito bytecode di estensione .class e quello di runtime (Java Runtime Environment ) (JRE). La piattaforma Java è rappresentata dal JRE che attraverso il bytecode permette alla JVM di eseguire qualunque programma o applicazione che lo possa generare. Possono essere quindi definiti dei veri e propri linguaggi JVM adatti a tale scopo promuovendo l’interoperabilità di tutto l’ecosistema Java.

Essendo un ambiente platform-independent, la piattaforma Java pùo eseguire più lentamente del codice basato sulla macchina sottostante. Tuttavia i progressi nelle tecnologie dei compilatori e delle macchine virtuali stanno portando le prestazioni vicine a quelle del codice macchina senza minacciare la portabilità.

Java Virtual Machine

La Java Virtual Machine (JVM) è la pietra angolare della piattaforma Java. E’ il componente della tecnologia Java responsabile della sua indipendenza dall’hardware e dal sistema operativo sottostante, delle dimensioni ridotte del codice compilato e dalla sua capacità di proteggere gli utenti da programmi dannosi.

A differenza della piattaforma Java, la JVM è platform-dependent; ogni sistema operativo ne fa una propria implementazione per farla girare al meglio delle proprie performance e caratteristiche.

Il suo compito è quello di fungere da collo di bottiglia andando a nascondere l’architettura della macchina sottostante alle varie applicazioni sviluppate, ma occupandosi di un bytecode file.class introduce il concetto di portabilità all’ambiente Java, che consente ad ogni sistema operativo che utilizza la propria versione, di poter eseguire qualsiasi programma previsto per essa.

La JVM ha un motore di esecuzione (execution engine) che per far eseguire un file bytecode messo a disposizione, si avvale di 2 componenti che sono stati creati a tale scopo, l’interpreter e il JIT compiler.

1. Interpreter Legge il bytecode e lo interpreta istruzione per istruzione in linguaggio macchina. All’occorrenza lo interpreta più volte alla stessa maniera, riducendo le performance del sistema sottostante.
2. Just in time compiler (JIT) Controbilancia gli svantaggi dell’interpreter avvalendosi di un’analisi statistica delle parti di codice più utilizzate e traducendole all’atto dell’esecuzione, migliorando le performance. E’ anche preparato per eseguire dinamicamente i file bytecode che potrebbero non essere disponibili all’inizio dell’esecuzione di un programma.

Caratteristiche dei Build systems

Un build system è un sistema di automazione per lo sviluppo di un software. Pùo gestire qualsiasi tipo di attività che comporti la traslazione di una forma di dati (l’input) in un’altra forma di dati (l’output).

In qualsiasi ambiente di sviluppo software, un build system incontra i seguenti scenari di cui si deve occupare:

• Gestione delle dipendenze
• Compilazione software
• Testing
• Generazione della documentazione
• Generazione di report
• Assemblaggio artefatti
• Firma artefatti

Regole

Un build system deve rispettare certe regole da seguire:

1. Scalabilità
2. Correttezza
3. Usabilità

Scalabilità

Dato un build system già aggiornato, per applicare un cambiamento al sistema e rieffettuare un processo di build dovrebbe richiedere un tempo proporzionale alla modifica svolta per consentirne il nuovo aggiornamento. Questa regola è necessaria perchè l’aggiornamento è la più comune operazione che viene fatta durante lo sviluppo.

I progetti crescono nel tempo, ma le loro dimensioni in un singolo ciclo di sviluppo rimangono pressocchè le stesse come se si trattasse di un piccolo progetto. La scalabilità di un build system è rapportata soltanto a ciò che riguarda la modifica fatta e non alla dimensione dell’intero progetto, perchè il trascorrere l’attesa che l’intero processo venga aggiornato è tempo perso.

Correttezza

Dato un build system in un determinato stato X, apportandogli una modifica e un successivo aggiornamento lo portano ad uno stato Y che se ne verrà poi annullata quella modifica, alla prossima esecuzione dovrà ritornare allo stato X.

La regola deve essere rispettata per assicurare che il programma usato per il testing di un progetto, sia effettivamente rappresentativo dei suoi file sorgenti. Non dovrebbe esserci alcuna preoccupazione per side-effect di funzioni, file o directory. Con l’annullamento delle modifiche e l’esecuzione dell’aggiornamento di un processo di build, si deve poter recuperare l’albero dei sorgenti dello stato precedente, cosicchè possa essere provato un altro approccio senza che il sistema possa risentirne e finire in un cattivo stato. Questa deve essere una normale operazione che deve essere supportata dal build system e non un caso specifico da essere gestito manualmente dallo sviluppatore.

Usabilità

Non ci devono essere modi differenti che lo sviluppatore debba ricordarsi per effettuare la build di un progetto. Indipendentemente da come e dove la modifica viene fatta, un build system deve funzionare attraverso l’esecuzione di un solo comando da poter usare in qualsiasi momento.