Refactor generale, Capitolo 5 Conclusioni

chapters/1 - Introduzione.tex

@@ -31,7 +31,8 @@ \subsection{DevOps}
 
 \paragraph{Continuous delivery} La distribuzione rappresenta l'insieme di operazioni finalizzate alla consegna del software agli utenti finali. Questo processo estende l'integrazione continua e si preoccupa di garantire la disponibilità costante di un artefatto di build pronto per il rilascio. L'effettivo rilascio di una nuova versione del software può avvenire in modo automatico oppure manualmente da parte dello sviluppatore. La filosofia DevOps fornisce linee guida e non regole rigide, lasciando al team di sviluppo il compito di progettare ed integrare un flusso adeguato alle necessità del progetto.
 
-\subsection{Distribuzione del software}
+% \subsection{Installazione del software}
+% La forma, cos'è un pacchetto software instllante, autocontenuto, aggiornamento del software, i package manager ed il loro    ruolo
 % L'importanza del come si distribuisce il software
 % Quanto capillarmente
 

chapters/3 - Design.tex

@@ -73,9 +73,9 @@ \section{Pipeline}
 \end{figure}
 L'interazione dei processi nella pipeline è raffigurato nella \Cref{fig:workflow-roles-summary}. L'\textbf{inizializza\-zio\-ne} trova spazio al primo posto e la sua esecuzione è strettamente necessaria per il proseguimento del flusso. L'\textbf{assemblaggio} e \textbf{build} sono eseguiti parallelamente mentre i \textbf{test} devono inevitabilmente dipendere dalla fase di assemblaggio per poter verificare l'output prodotto da quest'ultimo. Il \textbf{rilascio} infine, richiede che tutte le fasi descritte precedentemente siano eseguite con successo. I ruoli concernenti il lavoro descritto da questo elaborato sono: assemblaggio, test e rilascio.
 
-\subsection{Integrazione}
+\subsection{Interazione con il Build System}
 
-\paragraph{Interazione con il Build System} Per conseguire gli obiettivi dettati dai ruoli di assemblaggio e test è necessario l'utilizzo del build system. In particolare Alchemist sfrutta lo script \textit{gradle wrapper} per interagire con esso. Il file \textit{gradlew} è uno script che permette di eseguire Gradle senza doverlo installare globalmente: alla prima esecuzione controlla la versione richiesta definita in un file di configurazione, se quest'ultima non è presente allora il wrapper scarica questa e la utilizza per eseguire i task richiesti. I job, le unità di esecuzione della piattaforma GitHub Actions, consentono l'esecuzione di comandi nella \textit{shell} default (oppure una differente) del sistema operativo presente nel runner. In questo modo tramite comandi da shell è possibile eseguire lo script e fornire i task la cui esecuzione è richiesta come argomento di esso.
+Per conseguire gli obiettivi dettati dai ruoli di assemblaggio e test è necessario l'utilizzo del build system. In particolare Alchemist sfrutta lo script \textit{gradle wrapper} per interagire con esso. Il file \textit{gradlew} è uno script che permette di eseguire Gradle senza doverlo installare globalmente: alla prima esecuzione controlla la versione richiesta definita in un file di configurazione, se quest'ultima non è presente allora il wrapper scarica questa e la utilizza per eseguire i task richiesti. I job, le unità di esecuzione della piattaforma GitHub Actions, consentono l'esecuzione di comandi nella \textit{shell} default (oppure una differente) del sistema operativo presente nel runner. In questo modo tramite comandi da shell è possibile eseguire lo script e fornire i task la cui esecuzione è richiesta come argomento di esso.
 
 \paragraph{Test delle funzionalità} Lo \textit{status} di un job indica il risultato dell'esecuzione di esso e può essere: \textit{failure}, \textit{success} oppure \textit{skipped}. Un job è considerato in errore nel caso l'esecuzione di un comando restituisca un valore diverso da 0 e viceversa, perciò non sono necessarie particolari funzionalità per implementare un processo di verifica in quanto il comportamento comune dei comandi rispecchia le regole utilizzate. Lo stato \textit{skipped}, invece, si riferisce ai job non eseguiti secondo condizioni specifiche descritte dallo sviluppatore, è quindi possibile gestire un unico workflow e modificare il suo flusso a seconda dell'evento che ha innescato l'esecuzione. Il comportamento dei job di default all'interno di una pipeline è bloccante per cui il fallimento di uno porta all'interruzione dell'intera pipeline, come raffigurato nel diagramma \cref{fig:activity-diagram-job}.
 \begin{figure}[htb]
@@ -103,7 +103,8 @@ \subsection{Repository}
 Le funzioni sono eseguite nel seguente ordine: (i) prepare, eseguita appena dopo che è stato scaricato ed estratto il pacchetto indicato nella sorgente, (ii) pkgver, utilizzata per stabilire la versione del pacchetto se questa non è già stata impostata direttamente, (iii) build, i comandi necessari a compilare il software (se necessario), (iv) check, verifica che gli step precedenti siano stati eseguiti correttamente ed infine (v) package, l'installazione dei file nel filesystem. Nell'ambito di questo progetto solamente la funzione \textit{package} è necessaria in quanto il pacchetto sorgente contiene il software pronto per essere eseguito, la funzione dunque si occupa di posizionare i file nel sistema.
 Per non modificare direttamente il filesystem del computer installante, \texttt{makepkg} crea due directory \textit{pkg} e \textit{src}. All'interno di src, esso estrae il pacchetto e tutto il suo contenuto, mentre pkg consiste in un ambiente che simula il filesystem del sistema. In fase di installazione sarà il package manager a replicare la struttura della directory pkg nel filesystem del sistema installante.
 
-I pacchetti all'interno dell'\ac{aur} consistono in repository git contenenti il PKGBUILD ed altri file di configurazione opzionali, il processo di pubblicazione dunque è simile a qualsiasi progetto con un sistema di version control: la creazione di un commit e la pubblicazione di esso.
+%%LOOK AT ME
+I pacchetti all'interno dell'\ac{aur} consistono in repository \textit{git} contenenti il PKGBUILD ed altri file di configurazione opzionali, il processo di pubblicazione dunque è simile a qualsiasi progetto con un sistema di version control: la creazione di un commit e la pubblicazione di esso.
 
 \paragraph{Winget}\label{chap:winget} Il package manager winget presenta una struttura simile, un pacchetto è formato da diversi file \textit{manifest} i quali descrivono i meta-dati del pacchetto nel linguaggio YAML. A differenza del PKGBUILD, non ci sono script e non esistono funzioni, l'intera configurazione è descrittiva e non presenta la possibilità di inserire comandi da eseguire pre o post installazione. I file manifest si distinguono in: manifesto della versione, contenente dettagli identificativi del pacchetto, il manifesto delle impostazioni locali, il quale descrive la configurazione per uno specifico locale, ed il manifesto dell'installer, contenente l'URL dove reperire il pacchetto installante ed altre informazioni specifiche. Per semplificare il processo di creazione e pubblicazione dei pacchetti, Microsoft prevede l'utilizzo di uno script ``wingetcreate" che guida l'utente nella scelta dei parametri. Questo inoltre si presta ad essere utilizzato all'interno di pipeline \ac{cicd} per aggiornare pacchetti già presenti.
 

chapters/4 - Implementazione.tex

@@ -104,7 +104,7 @@ \subsection{Il processo di rilascio}
 \begin{figure}[htb]
 	\centering
 	\includegraphics[width=.95\linewidth]{figures/release-flow.pdf}
-	\caption{Diagramma dell'attività raffigurante il rilascio con i due job}
+	\caption{Diagramma dell'attività raffigurante il processo di rilascio su AUR e Winget}
 	\label{fig:release-flow}
 \end{figure}
 
@@ -162,6 +162,6 @@ \section{Valutazione ed ottimizzazione}
 	\label{fig:histogram}
 \end{figure}
 
-Innanzitutto, i risultati confermano un ottimo riscontro in relazione al requisito non funzionale, in particolare le due versioni \textit{b} e \textit{d} offrono prestazioni comparabili e contemporaneamente funzionalità aggiuntive rispetto la prima versione. L'utilizzo del build system peggiora notevolmente le prestazioni: la quarta versione offre un miglioramento sostanziale rispetto la terza, la quale utilizza una configurazione similarmente sequenziale. La seconda versione (\textit{b}) ottiene risultati comparabili alla quarta (\textit{d}), sebbene questa non utilizzi il caricamento e scaricamento degli artefatti. Ciò è dovuto alla mancanza del job incaricato al rilascio all'interno dei flussi analizzati. Mentre la versione \textit{d} ottiene gli artefatti da job assemblatori eseguiti precedentemente, la \textit{b} li genera nuovamente prima del loro rilascio. Lo stesso test condotto su esecuzioni del flusso completo avrebbero decretato un netto vantaggio della quarta versione rispetto le altre prese in esame.
+Innanzitutto, i risultati confermano un ottimo riscontro in relazione al requisito non funzionale, in particolare le due versioni \textit{b} e \textit{d} offrono prestazioni comparabili e contemporaneamente funzionalità aggiuntive rispetto la prima versione. L'utilizzo del build system peggiora notevolmente le prestazioni: la quarta versione offre un miglioramento sostanziale rispetto la terza, la quale utilizza una configurazione similarmente sequenziale. La seconda versione (\textit{b}) ottiene risultati comparabili alla quarta (\textit{d}), sebbene questa non utilizzi il caricamento e scaricamento degli artefatti. Ciò è dovuto alla mancanza del job incaricato al rilascio all'interno dei flussi analizzati. Mentre la versione \textit{d} ottiene gli artefatti da job assemblatori eseguiti precedentemente, la \textit{b} li genera nuovamente prima del loro rilascio. Lo stesso test condotto su esecuzioni del flusso completo avrebbe decretato un netto vantaggio della quarta versione rispetto le altre prese in esame.
 
-Dalle analisi dei dati risulta evidente come l'interazione con il build system, in particolare Gradle, prolunga l'esecuzione dei task per via delle fasi di inizializzazione dello strumento. L'utilizzo di un task, \texttt{testJpackageOutput}, per verificare la validità dei pacchetti è risultato quindi controproducente. Sebbene quest'ultimo permetta una configurazione semplificata nel workflow, l'utilizzo di comandi shell è indicato per svolgere semplici azioni che non richiedono particolari dipendenze tali da essere necessariamente integrate nel build system.
+Dall'analisi dei dati risulta evidente come l'interazione con il build system, in particolare Gradle, prolunga l'esecuzione dei task per via delle fasi di inizializzazione dello strumento. L'utilizzo di un task, \texttt{testJpackageOutput}, per verificare la validità dei pacchetti è risultato quindi controproducente. Sebbene quest'ultimo permetta una configurazione semplificata nel workflow, l'utilizzo di comandi shell è indicato per svolgere semplici azioni che non richiedono particolari dipendenze tali da richiedere l'utilizzo del build system.

chapters/5 - Conclusioni.tex

@@ -1,15 +1,24 @@
 %!TEX root = ../thesis-main.tex
 
 \chapter{Conclusioni}
-% Dimostrare i link con le release, installazione da AUR e da Winget
+% Dimostrare i link con le release, installazione da AUR e da Wing
+Quanto discusso nell'elaborato nel suo complesso ha consentito la distribuzione del software Alchemist in modo automatico in formati standard delle piattaforme coinvolte, all'interno di due principali repository pubblici rappresentanti due famiglie di sistemi operativi completamente differenti. Gli obiettivi posti sono stati raggiunti grazie ad una valutazione degli strumenti adibiti alla pacchettizzazione che il panorama \ac{jvm} offre, e grazie all'utilizzo di tecnologie come Gradle e GitHub Actions, sono state integrate all'interno del flusso di integrazione e distribuzione continua del progetto. L'autovalutazione ha poi evidenziato come migliorare il lavoro svolto mediante tecniche di ottimizzazione.
 
+\begin{figure}[htb]
+	\centering
+	\includegraphics[width=.8\linewidth]{figures/alchemist-aur.png}
+	\caption{Pagina web raffigurante il pacchetto Alchemist pubblicato sul repository AUR}
+	\label{fig:aur-web}
+\end{figure}
 
-\section{Sviluppi futuri}
-
-L'implementazione descritta da questo elaborato ha consentito la distribuzione del software in diversi 
+Il conseguimento degli obiettivi è osservabile su GitHub nella sezione dei rilasci\footnote{https://github.com/AlchemistSimulator/Alchemist/releases}, dove è possibile notare la possibilità di scaricare i diversi pacchetti installanti per ogni sistema operativo. Mediante invece l'utilizzo dei package manager è possibile installare ed aggiornare Alchemist con l'utilizzo di un semplice comando. Su Windows, previa installazione di winget, attraverso:
+\texttt{winget install Unibo.alchemist}
+e su Arch e derivate, previa autorizzazione all'installazione dall'Arch User Repository\footnote{https://aur.archlinux.org/packages/alchemist}(\Cref{fig:aur-web}), tramite \texttt{pamac} per Manjaro o più generalmente \texttt{yay}.
+L'utilizzo dei package manager assicura all'utente l'installazione dell'ultima versione di Alchemist e mediante le funzionalità da questo offerte è altrettanto semplice aggiornare la sua versione, in modo da garantire l'utilizzo agli utenti delle ultime funzionalità e correzioni. 
 
+\section{Sviluppi futuri}
+L'implementazione descritta da questo elaborato ha aperto nuove possibilità di distribuzione del progetto mediante l'introduzione della pacchettizzazione. Attraverso lo sviluppo di processi automatici di pubblicazione il software è stato distribuito all'interno di due principali repository di riferimento. Le possibilità di estensione del progetto sono numerose, in quanto esistono molteplici package manager nel panorama esteso dei sistemi operativi. Nei seguenti punti sono riassunti i principali spunti per migliorare ed estendere il processo:
 \begin{itemize}
-	\item \textbf{Distribuzione su Homebrew}: le piattaforme su cui Alchemist è distribuito non comprendono il sistema operativo MacOs. Ciò è dovuto alla necessità di utilizzare un dispositivo che utilizza il sistema operativo per verificare la corretta integrazione. Il package manager Homebrew rappresenta una valida opzione per ampliare maggiormente il bacino di utenti di Alchemist.
-	\item \textbf{Reflection e jlink}: l'utilizzo di Jlink
-	\item \textbf{Supporto a Snap e Flatpak}: i pacchetti containerizzati offrono una valida alternativa e coprono una vasta gamma di distribuzioni dell'ambiente Linux. La loro implementazione nel flusso di integrazione e distribuzione continua di Alchemist contribuirebbe ad un ampliamento delle piattaforme supportate dal software. % Add stuff
+	\item \textbf{Distribuzione su Homebrew}: i repository su cui Alchemist è distribuito non comprendono il sistema operativo MacOs. Il package manager Homebrew realizzato per MacOs rappresenta una valida opzione per raggiungere un pubblico più ampio attraverso modalità di installazione semplici e funzionali.
+	\item \textbf{Supporto a Snap}: i pacchetti containerizzati offrono una valida alternativa e coprono una vasta gamma di distribuzioni dell'ambiente Linux. La loro implementazione nel flusso di integrazione e distribuzione continua di Alchemist contribuirebbe ad un ulteriore ampliamento delle distribuzioni supportate dal software. 
 \end{itemize}