Capitolo 4: Valutazione ed Ottimizzazione

chapters/3 - Design.tex

@@ -31,7 +31,7 @@ \section{Build system}
 \subsection{Lo strumento jpackage}\label{sec:design-jpackage}
 Lo strumento \ac{cli} \textit{jpackage} offre un'interfaccia munita di diverse opzioni per configurare e personalizzare a piacimento i pacchetti in output. Esistono parametri generici, compatibili con tutte le piattaforme, e parametri specifici che vanno a modificare attributi particolari alla tipologia di pacchetto in output scelta. Uno dei motivi che ha portato alla scelta di \textit{jpackage} rispetto ad altri software è la capacità di includere autonomamente una \textit{runtime-image} di Java, ossia una \ac{jre} ridotta di dimensioni all'interno del pacchetto. La combinazione di una \textit{runtime-image} e degli archivi Java (JAR) necessari all'esecuzione dell'applicazione costituiscono l'\textit{application-image}: un pacchetto autocontenuto che include l'applicazione, assieme una \ac{jvm} ed alle librerie necessarie per eseguire quell'applicazione sulla piattaforma di destinazione.
 
-\paragraph{Application image} Alchemist è un progetto modulare ed ogni modulo è distribuito in un archivio JAR specifico. Come descritto nella documentazione\footnote{https://alchemistsimulator.github.io/howtos/preparation/jar/index.html} il software predispone due modalità di utilizzo stand-alone attraverso l'esecuzione degli archivi Java. La prima modalità consiste nell'inclusione dei singoli moduli richiesti come \textit{classpath} del processo di esecuzione. La seconda modalità sfrutta l'archivio denominato ``full", ossia un \textit{fat-jar} contenente tutti i moduli e tutte le dipendenze necessarie all'esecuzione del software in tutte le sue parti. In ottica di ridurre le dimensioni del pacchetto e velocizzare il processo di impacchettamento, jpackage costruirà l'\textit{application-image} utilizzando quest'ultimo. La posizione ed organizzazione dei file è diversa a seconda della piattaforma di destinazione del pacchetto, il risultato dell'installazione in un ambiente Linux è descritto nella figura \ref{fig:activity-interaction-diagram}.  
+\paragraph{Application image} Alchemist è un progetto modulare ed ogni modulo è distribuito in un archivio JAR specifico. Come descritto nella documentazione\footnote{https://alchemistsimulator.github.io/howtos/preparation/jar/index.html} il software predispone due modalità di utilizzo stand-alone attraverso l'esecuzione degli archivi Java. La prima modalità consiste nell'inclusione dei singoli moduli richiesti come \textit{classpath} del processo di esecuzione. La seconda modalità sfrutta l'archivio denominato ``full", ossia un \textit{fat-jar} contenente tutti i moduli e tutte le dipendenze necessarie all'esecuzione del software in tutte le sue parti. In ottica di ridurre le dimensioni del pacchetto e velocizzare il processo di impacchettamento, jpackage costruirà l'\textit{application-image} utilizzando quest'ultimo. La posizione ed organizzazione dei file è differente a seconda della piattaforma di destinazione del pacchetto, il risultato dell'installazione in un ambiente Linux è descritto nella figura \ref{fig:activity-interaction-diagram}.  
 
 \begin{figure}
 	\centering

chapters/4 - Implementazione.tex

@@ -76,7 +76,7 @@ \subsection{Meta-dati}
 
 \section{Sviluppo della pipeline}
 
-L'implementazione descritta consente attraverso l'utilizzo del build system di generare i pacchetti ed i corrispondenti meta-dati richiesti per la distribuzione. Il passo successivo è integrare la loro esecuzione all'interno della pipeline, in modo da conseguire gli obiettivi di integrazione e distribuzione continua. La sfida principale consiste nell'inserire i nuovi step senza stravolgere la struttura ed il flusso iniziale.
+L'implementazione descritta consente attraverso l'utilizzo del build system di generare i pacchetti ed i corrispondenti meta-dati richiesti per la distribuzione. Il passo successivo è integrare la loro esecuzione all'interno della pipeline, in modo da conseguire gli obiettivi di integrazione e distribuzione continua. La sfida principale consiste nell'inserire i nuovi step senza stravolgere la struttura del flusso iniziale.
 
 \subsection{Generazione degli artefatti}
 
@@ -126,11 +126,11 @@ \section{Valutazione ed ottimizzazione}
 
 Lo sviluppo della pipeline ha richiesto diverse revisioni prima di ottenere il risultato finale voluto. Il flusso di integrazione e distribuzione continua per sua natura è innescato continuamente ed è perciò fondamentale sfruttare le funzionalità fornite dall'API di Actions per ottimizzare e ridurre i tempi di esecuzione di esso nel complesso. Per ottenere l'ottimizzazione desiderata esistono diverse accortezze nella configurazione dei workflow capaci di registrare incrementi prestazionali contenuti, ma che nel lungo periodo impattano positivamente lo sviluppo progetto. Le principali ottimizzazioni utilizzate sono elencate di seguito.
 \begin{itemize}
-	\item fail-fast
-	\item concurrency group
-	\item upload
-	\item timeout
-	\item build system
+	\item \textbf{Fail-fast}: questa ottimizzazione si applica ai flussi di lavoro che definiscono una strategia a matrice. Se il fail-fast è abilitato, la piattaforma annullerà tutti i compiti in corso e in coda nella matrice non appena uno qualsiasi dei compiti in essa fallisce.
+	\item \textbf{Concurrency group}: consente di inserire job all'interno di gruppi, identificati da una chiave, nella quale un solo job per volta viene eseguito. Normalmente Actions permette l'esecuzione dello stesso workflow, job e step parallelamente, ciò significa che la pubblicazione di diversi commit rapidamente  innesca l'esecuzione di più flussi paralleli. Se il flag \texttt{cancel-in-progress} è attivo e durante l'esecuzione di un job un altro componente dello stesso gruppo viene inserito in coda, quest'ultimo prende il posto ed elimina il job corrente.
+	\item \textbf{Artefatti}: l'utilizzo delle action \textit{upload-artifact} e \textit{download-artifact} consentono di distribuire gli artefatti tra i job dei workflow. In generale, l'approccio preferibile è di stabilire dei job assemblatori che generano e forniscono gli artefatti a successivi job di test o rilascio. Il caricamento di file anche di notevoli dimensioni è estremamente più conveniente rispetto alla rigenerazione, file di dimensioni dell'ordine delle centinaia di megabyte sono processati in poche decine di secondi.
+	\item \textbf{Timeout}: invece di fare affidamento sul timeout predefinito dei compiti, che è di 360 minuti (6 ore), i flussi di lavoro possono impostare esplicitamente un timeout personalizzato. L'opzione risulta efficace per interrompere i flussi di lavoro che si protraggono inutilmente a lungo, il che può essere particolarmente utile per evitare che i contributori, tramite pull request, inneschino flussi di lavoro prolungati.
+	\item \textbf{Build system}: esso, nel caso specifico di Gradle, introduce un overhead dettato dalla necessità ad ogni esecuzione di effettuare le fasi di inizializzazione e configurazione. Sebbene implementi tecniche di ottimizzazione, l'utilizzo di Gradle, in particolare nei progetti di grandi dimensioni, può incrementare il tempo di esecuzione di un job di diversi minuti.
 \end{itemize}