Capitolo 1: DevOps e diversi refactoring nei capitoli successivi

bibliography.bib

@@ -31,4 +31,32 @@ @article{github-actions-diffusion
 	timestamp    = {Wed, 01 Nov 2023 08:59:33 +0100},
 	biburl       = {https://dblp.org/rec/journals/ese/WesselVGT23.bib},
 	bibsource    = {dblp computer science bibliography, https://dblp.org}
+}
+
+@article{article,
+	author = {Wasserman, Anthony},
+	year = {2011},
+	month = {07},
+	pages = {11-22},
+	title = {How the Internet transformed the software industry},
+	volume = {2},
+	journal = {J. Internet Services and Applications},
+	doi = {10.1007/s13174-011-0019-x}
+}
+
+@article{DBLP:journals/corr/abs-2301-09429,
+	author       = {Fatih Bildirici and
+	{\"{O}}m{\"{u}}r Akdemir},
+	title        = {From Agile to DevOps, Holistic Approach for Faster and Efficient Software
+	Product Release Management},
+	journal      = {CoRR},
+	volume       = {abs/2301.09429},
+	year         = {2023},
+	url          = {https://doi.org/10.48550/arXiv.2301.09429},
+	doi          = {10.48550/ARXIV.2301.09429},
+	eprinttype    = {arXiv},
+	eprint       = {2301.09429},
+	timestamp    = {Thu, 26 Jan 2023 15:26:31 +0100},
+	biburl       = {https://dblp.org/rec/journals/corr/abs-2301-09429.bib},
+	bibsource    = {dblp computer science bibliography, https://dblp.org}
 }

chapters/1 - Introduzione.tex

@@ -4,25 +4,42 @@ \chapter{Introduzione}
 \label{chap:introduction}
 %----------------------------------------------------------------------------------------
 
-Introduzione 
-
-(Il problema, software oggigiorno, l'importanza della qualità del software e altre caratteristiche di ingegneria del software, come automatizzare migliora la qualità eliminando l'intervento umano)
+Il mondo del software ha scritto diverse decadi di storia. Sin dagli anni '50, quando i primi calcolatori programmabili hanno fatto il loro ingresso sul mercato, il software ha assunto un ruolo sempre più pervasivo nella vita quotidiana delle persone. Oltre ad essere parte integrante dei sistemi informativi delle aziende, lo possiamo trovare anche all'interno di automobili, elettrodomestici e tantissimi strumenti con la quale abbiamo a che fare nella nostra quotidianità. La crescente diffusione del software ha introdotto la necessità di progettare metodologie di sviluppo solide e versatili. Uno dei primi è il \textbf{modello a cascata} il quale struttura il processo di realizzazione del software in fasi sequenziali lineari. Il modello riprende la tipica organizzazione della produzione manifatturiera e fu progressivamente abbandonato con l'evolversi delle richieste del mercato. Successivamente prese piede il concetto di modelli iterativi come il \textbf{modello a spirale} in cui il processo di sviluppo è suddiviso in fasi multiple ripetute più volte (iterazioni). Gli ultimi decenni hanno dato vita a un nuovo modello, considerato lo standard dell'industria, la \textbf{metodologia agile}. Quest'ultima non rappresenta un unico modello, ma un insieme di modelli iterativi costruiti sulla base dei principi definiti all'interno del manifesto agile. Questi mettono in primo piano un ambiente autonomo e dinamico in cui sono fondamentali: cicli di sviluppo brevi, continui miglioramenti, la comunicazione col cliente e la consegna tempestiva di funzionalità. Il progetto esposto in questo documento introduce un evoluzione del concetto agile nato recentemente nel mondo dello sviluppo del software, conosciuto come ``DevOps".
 
 \section{Contesto}
 
-(Un'introduzione teorica degli elementi sotto elencati, cosa servono, esempi di software che risolvono questo problema, evoluzione di questi negli ultimi anni )
+Con l'avvento di internet il concetto di software come un entità sviluppata e finita ha completamente cessato di esistere. Mediante la rete è diventato semplice ed efficiente distribuire un programma e fornire un ulteriore supporto attraverso aggiornamenti evolutivi e correttivi. Il fenomeno è cresciuto tanto da aver dato luce alla pratica del rilascio di applicazioni deliberatamente non complete, le quali attraverso il feedback degli utenti evolvono verso un prodotto finito. Il manifesto agile ha introdotto la cultura di emettere frequenti rilasci di nuove versioni del software, rendendo la distribuzione un punto cardine all'interno del ciclo di vita di esso. Dietro lo sviluppo rapido di nuove funzionalità è necessario il rilascio di queste altrettanto velocemente, la filosofia DevOps nasce per soddisfare questa esigenza.
+
+\subsection{DevOps}
+La metodologia DevOps (termine nato dalla contrazione di ``Development" ed ``Operations") si è formata intorno al 2008 con l'idea chiave di unire il team di sviluppo ed il team delle operazioni (infrastruttura). Spesso accade all'interno di organizzazioni di grandi dimensioni che questi due componenti fondamentali siano separati, ossia il rilascio dell'applicazione avviene dopo che il processo di sviluppo è terminato, senza la possibilità tra i due di coordinarsi durante l'esecuzione. La filosofia DevOps promuove l'unione dei due reparti per garantire la distribuzione di software di maggior qualità in modo continuo e controllato. Essi sono considerati un'unica entità e cooperano seguendo un modello come descritto nella figura \ref{fig:devops-process}.
+\begin{figure}[htb]
+	\centering
+	\includegraphics[width=.9\linewidth]{figures/devops-process.png}
+	\caption{Le fasi della metodologia DevOps}
+	\label{fig:devops-process}
+	%https://italiancoders.it/introduzione-al-devops/
+\end{figure}
+Il modello mette in risalto le fasi e il rispettivo reparto di appartenenza, mentre le due fasi ``plan" e ``release" fungono da ponte per comporre un'unica entità.
+
+Uno dei principi base della filosofia DevOps è l'utilizzo di pratiche di \ac{cicd}, ossia automazione dell'integrazione e distribuzione del software. Automatizzando le fasi descritte precedentemente si elimina l'intervento umano garantendo rilasci più rapidi e di maggior qualità.
+
+\paragraph{Continuous integration} L'integrazione è costituita dalle operazioni di build e test del codice, essa diventa continuativa dal momento che si inserisce l'automazione nell'equazione. Un processo generalmente è formato secondo i seguenti step: (i) gli sviluppatori introducono nuovo codice nel progetto attraverso il software di \textit{version control} (per esempio git), (ii) un server ottiene la modifica ed esegue il build ed i test del progetto nella sua interezza, (iii) una volta completato il processo comunica l'esito delle operazioni agli sviluppatori. In questo modo le nuove parti di codice sono costantemente controllate riducendo al minimo la potenziale presenza di bug, migliorando in tutto e per tutto la qualità del progetto.
+Un fattore molto importante è la stesura di test: più questi hanno una copertura maggiore, più saranno lenti nell'esecuzione e rallenteranno il processo di integrazione. È essenziale quindi calibrare la loro copertura secondo le esigenze del progetto, ricordando che una copertura totale migliora notevolmente la qualità del prodotto.
 
-\subsection{Build automation}
-\subsection{Continuous integration}
-\subsection{Continuous delivery}
-\paragraph{Pipeline}
+\paragraph{Continuous delivery} La distribuzione è l'insieme delle operazioni atte a consegnare il software agli utenti finali.
 
-\subsection{Alchemist}\label{sec:alchemist}
+\paragraph{Le pipeline}
+
+\subsection{Un software complesso: Alchemist}\label{sec:alchemist}
 
 (Cos'è alchemist, utilizzo, tecnologie utilizzate, architettura, progettazione)
 
+\paragraph{Open source}
+
 \section{Obiettivi}
 
+\subsection{Motivazioni}
+
 \paragraph{Struttura della tesi}
 
 La struttura di questo paper

chapters/2 - Analisi.tex

@@ -48,9 +48,9 @@ \section{Pacchettizzazione}\label{sec:packaging}
 
 \subsection{Soluzioni}
 
-Nell'ottica di semplificare la configurazione di questo processo lo strumento selezionato deve supportare le tre principali piattaforme descritte nei requisiti precedentemente. Tra gli strumenti analizzati due molto differenti si sono distinti, vale a dire: \textit{jpackage}, comando disponibile nel \ac{jdk} dalla versione 14 adibito alla produzione di pacchetti auto-contenuti con \ac{jre} integrata e \textit{GraalVM}, un \ac{jdk} sviluppato da Oracle che fornisce un compilatore \ac{jit} e \ac{aot} per java. Il termine \ac{jit} descrive il comportamento normale di ogni \ac{jvm}: il \textit{java compiler} traduce il programma ad alto livello in \textit{bytecode}, successivamente la \ac{jvm} trasforma il bytecode in linguaggio macchina specifico per l'architettura sottostante eseguendo dunque una compilazione dinamica. In contrasto la tecnica \ac{aot} ricorda i linguaggi di programmazione compilati, la compilazione è statica ed avviene prima dell'esecuzione del programma. Il compilatore \ac{aot} chiamato ``Native Image", consente di compilare un programma java (ed altri linguaggi di programmazione) ottenendo in output un eseguibile nativo per ogni piattaforma. Quest'ultimo inoltre porta con sè diversi vantaggi come: un minor costo in risorse CPU e memoria, tempi di avvio minori e dimensioni ridotte rispetto un normale programma java distribuito con un \ac{jre}. L'annessione di un JRE non è quindi necessaria, l'eseguibile prodotto contiene tutto il necessario per l'esecuzione dell'applicazione, eliminando la necessità di una macchina virtuale java. La compilazione \ac{aot} però ha dei requisiti, uno di questi fondamentale è la \textit{closed world assumption}: ossia ogni parte di codice raggiungibile in esecuzione lo deve essere anche in fase di build, altrimenti quei componenti non appariranno nell'eseguibile finale. Ciò accade perché native image svolge un analisi statica del codice e dunque non lo esegue, alcune funzionalità come la reflection oppure il caricamento dinamico non sono supportate e richiedono una soluzione alternativa.
+Nell'ottica di semplificare la configurazione di questo processo lo strumento selezionato deve supportare le tre principali piattaforme descritte nei requisiti precedentemente. Tra gli strumenti analizzati due molto differenti si sono distinti, vale a dire: \textit{jpackage}, comando disponibile nel \ac{jdk} dalla versione 14 adibito alla produzione di pacchetti auto-contenuti con \ac{jre} integrata e \textit{GraalVM}, un \ac{jdk} sviluppato da Oracle che fornisce un compilatore \ac{jit} e \ac{aot} per java. Il termine \ac{jit} descrive il comportamento normale di ogni \ac{jvm}: il \textit{java compiler} traduce il programma ad alto livello in \textit{bytecode}, successivamente la \ac{jvm} trasforma il bytecode in linguaggio macchina specifico per l'architettura sottostante eseguendo dunque una compilazione dinamica. In contrasto la tecnica \ac{aot} ricorda i linguaggi di programmazione compilati, la compilazione è statica ed avviene prima dell'esecuzione del programma. Il compilatore \ac{aot} chiamato ``Native Image", consente di compilare un programma java (ed altri linguaggi di programmazione) ottenendo in output un eseguibile nativo per ogni piattaforma. Quest'ultimo inoltre porta con sè diversi vantaggi come: un minor costo in risorse CPU e memoria, tempi di avvio minori e dimensioni ridotte rispetto un normale programma java distribuito con un \ac{jre}. L'annessione di un JRE è superfluo, l'eseguibile prodotto contiene tutto il necessario per l'esecuzione dell'applicazione. La compilazione \ac{aot} però ha dei requisiti, uno di questi fondamentale è la \textit{closed world assumption}: ossia ogni parte di codice raggiungibile in esecuzione lo deve essere anche in fase di build, altrimenti l'eseguibile finale sarà incompleto. Ciò accade perché native image svolge un analisi statica del codice, alcune funzionalità come la reflection oppure il caricamento dinamico non sono supportate e richiedono una soluzione alternativa.
 
-In contrasto jpackage fornisce uno strumento interessante, il quale non richiede modifiche all'applicativo e si trova pre-installato in tutti i \ac{jdk} dalla versione 14 in poi. Supporta nativamente l'annessione di un \ac{jre} utilizzando \textit{jlink}, produce diverse tipologie di pacchetti per ogni piattaforma ed è completamente controllabile da interfaccia \ac{cli}: particolare molto d'aiuto nei successivi step di automazione. Le tipologie di pacchetti generabili sono elencati di seguito:
+In contrasto jpackage fornisce uno strumento interessante, il quale non richiede modifiche all'applicativo ed è pre-installato in tutti i \ac{jdk} dalla versione 14 e successive. Supporta nativamente l'annessione di un \ac{jre} utilizzando \textit{jlink}, produce diverse tipologie di pacchetti per ogni piattaforma ed è completamente controllabile da interfaccia \ac{cli}. Le tipologie di pacchetti generabili sono elencate di seguito:
 \begin{itemize}
 	\item EXE e MSI per Windows
 	\item RPM e DEB per Linux