Verso una teoria delle differenze tra documenti semi-strutturati

I sistemi di versionamento moderni quali "git" o "svn" sono ad oggi basati su svariati algoritmi di analisi delle differenze (detti algoritmi di diffing) tra documenti (detti versioni). Uno degli algoritmi impiegati con maggior successo a tal proposito è il celebre "diff" di Unix. Tale programma è in grado di rilevare le modifiche necessarie da apportare ad un documento al fine di ottenerne un altro in termini di aggiunta o rimozione di linee di testo. L'insieme di tali modifiche prende nome di "delta". La crescente richiesta e applicazione dei documenti semi-strutturati (ed in particolar modo dei documenti XML) da parte della comunità informatica soprattutto in ambito web ha motivato la ricerca di algoritmi di diffing più raffinati che operino al meglio su tale tipologia di documenti. Svariate soluzioni di successo sono state discusse; algoritmi ad alte prestazioni capaci di individuare differenze più sottili della mera aggiunta o rimozione di testo quali il movimento di interi nodi, il loro riordinamento finanche il loro incapsulamento e così via. Tuttavia tali algoritmi mancano di versatilità. L'incapsulamento di un nodo potrebbe essere considerata una differenza troppo (o troppo poco) generale o granulare in taluni contesti. Nella realtà quotidiana ogni settore, pubblico o commerciale, interessato a rilevare differenze tra documenti ha interesse nell'individuarne sempre e soltanto un sottoinsieme molto specifico. Si pensi al parlamento italiano interessato all'analisi comparativa di documenti legislativi piuttosto che ad un ospedale interessato alla diagnostica relativa alla storia clinica di un paziente. Il presente elaborato di tesi dimostra come sia possibile sviluppare un algoritmo in grado di rilevare le differenze tra due documenti semi-strutturati (in termini del più breve numero di modifiche necessarie per trasformare l'uno nell'altro) che sia parametrizzato relativamente alle funzioni di trasformazione operanti su tali documenti. Vengono discusse le definizioni essenziali ed i principali risultati alla base della teoria delle differenze e viene dimostrato come assunzioni più blande inducano la non calcolabilità dell'algoritmo di diffing in questione.

Lo sviluppo cooperativo del software

Studio degli strumenti Open Source usati per lo sviluppo cooperativo del software, delle loro possibili interazioni e di come esse facilitino lo sviluppo cooperativo.

The Scrum approach to software development

Agile methodologies have become the standard approach to software development. The most popular and used one is Scrum. Scrum is a very simple and flexible framework that respond to unpredictability in a really effective way. However, his implementation must be correct, and since Scrum tells you what to do but not how to do it, this is not trivial. In this thesis I will describe the Scrum Framework, how to implement it and a tool that can help to do this. The thesis is divided into three parts. The first part is called Scrum. Here I will introduce the framework itself, its key concepts and its components. In Scrum there are three components: roles, meetings and artifacts. Each of these is meant to accomplish a series of specific tasks. After describing the “what to do”, in the second part, Best Practices, I will focus on the “how to do it”. For example, how to decide which items should be included in the next sprint, how to estimate tasks, and how should the team workspace be. Finally, in the third part called Tools, I will introduce Visual Studio Online, a cloud service from Microsoft that offers Git and TFVC repositories and the opportunity to manage projects with Scrum. == Versione italiana: I metodi Agile sono diventati l’approccio standard per lo sviluppo di software. Il più famoso ed utilizzato è Scrum. Scrum è un framework molto semplice e flessibile che risponde ai cambiamenti in una maniera molto efficace. La sua implementazione deve però essere corretta, e visto che Scrum ci dice cosa fare ma non come farlo, questo non risulta essere immediato. In questa tesi descriverò Scrum, come implementarlo ed uno strumento che ci può aiutare a farlo. La tesi è divisa in tre parti. La prima parte è chiamata Scrum. Qui introdurrò il framework, i suoi concetti base e le sue componenti. In Scrum ci sono tre componenti: i ruoli, i meeting e gli artifact. Ognuno di questi è studiato per svolgere una serie di compiti specifici. Dopo aver descritto il “cosa fare”, nella seconda parte, Best Practices, mi concentrerò sul “come farlo”. Ad esempio, come decidere quali oggetti includere nella prossima sprint, come stimare ogni task e come dovrebbe essere il luogo di lavoro del team. Infine, nella terza parte chiamata Tools, introdurrò Visual Studio Online, un servizio cloud della Microsoft che offre repository Git e TFVC e l’opportunità di gestire un progetto con Scrum.

Implementazione di un sistema di Continuous Integration e Continuous Deployment per il rilascio di microservizi Cloud Native su piattaforma Kubernetes

Il processo di sviluppo di un’applicazione comprende più fasi, ognuna strettamente correlata alle altre. Una delle fasi di questo processo è il rilascio del software, che consiste nel rendere disponibile agli utenti l’applicazione caricandone l’eseguibile su un server, sul quale verrà poi eseguita. Per un’azienda di sviluppo software è particolarmente importante automatizzare e standardizzare il processo di rilascio del software, allo scopo di renderlo più veloce e di diminuire il tempo che intercorre fra una modifica e il momento in cui questa viene effettivamente resa disponibile per gli utenti, ottimizzando infine l’impegno degli sviluppatori. La presente tesi descrive l’implementazione di un sistema di Continuous Integration e Continuous Deliveliry scalabile su una software house con più di 900 dipendenti suddivisi in decine di team, ognuno dei quali ha in carico lo sviluppo di vari software. Le applicazioni realizzate dai team sono generalmente microservizi in esecuzione all’interno di container su piattaforma Kubernetes. Sono state quindi valutate le varie alternative per la realizzazione di questo sistema, analizzandone pro e contro, scegliendo infine GitLab per la parte di Continuous Integration e ArgoCD per la parte di Continuous Deployment. Nei vari capitoli viene quindi analizzata l’infrastruttura esistente e vengono illustrati i vantaggi e svantaggi delle varie soluzioni considerate. Per i due software selezionati viene invece descritto il lavoro svolto, con dettagli sul funzionamento del sistema e la configurazione necessaria per il corretto funzionamento dell’intero processo. La soluzione realizzata effettua build, test, code validation e deploy delle applicazioni seguendo un pattern GitOps, con un repository git contenente la configurazione attuale delle applicazioni, permettendo rollback in caso di problematiche e garantendo un alto livello di sicurezza attraverso il mantenimento dello storico della configurazione e della versione delle applicazioni.