Merge branch 'argomenti/32' into ceri/32-review

src/06_git-workflow/00_index.md

@@ -9,3 +9,4 @@ Lavorando in un team, è quindi necessario stabilire delle politiche sui tipi e
 - [**Hosting centralizzato**](./02_hosting-centralizzato.md): repository centrali git
 - [**Gerrit**](./03_gerrit.md): meccanismo di review in team
 - [**Strumenti dell'opensource**](./04_strumenti-opensource/00_index.md): strumenti opensource per build automation e bug tracking
+- [**Unified Process**](./05_unified-process.md): meta-modello di processo dai creatori di UML
\ No newline at end of file

src/06_git-workflow/01_gitflow.md

 # GitFlow
 
-GitFlow è una tecnica di organizzazione dei branch e delle repository che prevede la creazione sia di diversi tipi di branch a vita limitata che il loro _merge_ guidato.
+GitFlow è una tecnica di organizzazione dei branch e delle repository che prevede la creazione sia di diversi tipi di branch a vita limitata che il loro _merge_ guidato, anche da remoto.
+
+Si tratta di una serie di comandi _shell_ che vengono uniti in uno script e percepiti da Git come un comando interno, data la sua natura. Infatti ogni Git non è altro che un wrapper di una serie di altri programmi che eseguono diverse funzioni.
 
 È disponibile online una [cheatsheet](https://danielkummer.github.io/git-flow-cheatsheet/) che fornisce una panoramica veloce delle principali operazioni e dei comandi di GitFlow. 
 Si tratta di uno strumento utile per chi è alle prime armi con questa tecnica di organizzazione dei branch, ma non esaustivo: per una comprensione più approfondita del metodo, è meglio integrarlo con altre risorse.
@@ -18,7 +20,7 @@ I branch e i tipi di branch previsti da GitFlow sono:
 
 In GitFlow, ci sono due branch che hanno una durata più lunga (teoricamente non hanno fine) rispetto ai branch temporanei utilizzati per lavorare su specifiche funzionalità o correzioni di bug:
 - __`master`__: contiene le versioni stabili del codice sorgente, pronte per essere consegnate o rilasciate al cliente o al pubblico. Queste versioni sono considerate _affidabili_ e _testate_, quindi possono essere utilizzate in produzione;
-- __`develop`__: è il ramo di integrazione in cui vengono integrati i contribuiti di tutti i gruppi; è anche il punto di partenza degli altri tipi di branch.
+- __`develop`__: è il ramo di __integrazione__, e non di sviluppo! Qui vengono integrati i contribuiti di tutti i gruppi ed è il punto di partenza degli altri tipi di branch su cui accadrà effetivamente il lavoro.
 
 Al termine di ogni rilascio, il contenuto del branch `develop` viene integrato nel branch `master`, che rappresenta la versione stabile del codice. Le _versioni notturne_, invece, sono versioni di sviluppo che vengono rilasciate periodicamente e contengono le ultime modifiche apportate al codice. Esse vengono create partendo dal branch `develop`, che rappresenta il punto di integrazione di tutti i contributi dei gruppi di lavoro.
 
@@ -26,9 +28,9 @@ Al termine di ogni rilascio, il contenuto del branch `develop` viene integrato n
 
 ![GitFlow feature](/assets/06_gitflow-feature.png)
 
-I __*feature branch*__ sono branch temporanei utilizzati per sviluppare nuove funzionalità o per correggere bug. __Possono essere creati solo a partire dal branch `develop`__ e vengono utilizzati per isolare il lavoro su una specifica funzionalità o problema dal resto del codice. 
+I __*feature branch*__ sono branch temporanei utilizzati per sviluppare nuove __user stories__ o per correggere bug. __Possono essere creati solo a partire dal branch `develop`__ e vengono utilizzati per isolare il lavoro su una specifica funzionalità o problema dal resto del codice. 
 Quando il lavoro è completato, il feature branch viene integrato di nuovo nel `develop` tramite un merge. 
-In questo modo, è possibile lavorare in modo organizzato su diverse funzionalità o problemi senza interferire tra loro.
+In questo modo, è possibile lavorare in modo organizzato e parallelo su diverse funzionalità o problemi senza interferire tra loro.
 Per integrare il lavoro svolto in un feature branch nel branch `develop`, è necessario eseguire un merge del feature branch nel `develop`. 
 Ci sono diversi modi di fare ciò, a seconda delle preferenze e delle esigenze specifiche.
 Un modo semplice di fare il merge è utilizzare il comando `git merge` dalla riga di comando. 
@@ -116,12 +118,12 @@ In git, i tag sono etichette che possono essere applicate a un commit per segnal
 In GitFlow, le release sono versioni stabili del codice che vengono rilasciate al pubblico o al cliente. 
 Ogni release viene creata partendo dal branch `develop` e viene gestita come un branch a sé stante, che viene chiuso una volta che tutte le modifiche previste sono state integrate. 
 Al contrario, le feature sono branch temporanei utilizzati per sviluppare nuove funzionalità o per correggere bug. 
-È possibile avere più feature aperte contemporaneamente, ma solo una release rimanere aperta in un dato istante.
+È possibile avere più feature aperte contemporaneamente, ma solo una relase rimane aperta in un dato istante.
 
 ## Hotfix
 
-Un _hotfix_ è una riparazione veloce di difetti urgenti senza dover aspettare la prossima release.
-È l'unico caso per cui non si parte da `develop`, ma dall'ultima - o una particolare - versione rilasciata su `master`.
+Un _hotfix_ è una riparazione veloce di difetti __urgenti__ senza dover aspettare la prossima release.
+È l'unico caso per cui non si parte da `develop`, ma dall'ultima - o una particolare - versione rilasciata su `master` e in `develop`.
 
 ![GitFlow hotfix](/assets/06_gitflow-hotfix.png)
 
@@ -155,13 +157,15 @@ $ git branch -d hotfix/CVE-123          # elimina il branch di hotfix
 
 Quali sono i limiti di git presentato così?
 
-git e GitFlow come sono stati esposti presentano numerosi vincoli, tra cui:
+git e GitFlow come sono stati esposti presentano numerosi vincoli, soprattuto se utilizzati in grandi team, tra cui:
 - la __mancanza di un sistema di autorizzazione granulare__, ovvero la possibilità di assegnare permessi in modo specifico e mirato a diverse funzionalità o risorse. Inoltre, non esiste una distinzione tra diversi livelli di accesso, quindi o si ha accesso completo a tutte le funzionalità o non si ha accesso a niente;
 - l'__assenza di code review__, ovvero il processo di revisione del codice sorgente da parte di altri sviluppatori prima che venga integrato nel codice base.
 
+Questi limiti vengono risolti da sovrastrutture che si basano su Git, come GitHub e le istanze di GitLab.
+
 ## `git request-pull` — _generates a summary of pending changes_
 
-Il tool `git request-pull` è un comando di git che serve per formattare e inviare una proposta di modifiche a un repository tramite una mailing list. 
+Il tool `git request-pull` è un comando di git che serve per formattare e inviare una proposta di modifiche a un repository tramite una mailing list dopo aver reso pubblici i propri commit su un proprio server. 
 Il comando crea un messaggio di posta elettronica che chiede al maintainer del repository di "pullare" le modifiche, ovvero di integrarle nel codice base. 
 Oggi, questa pratica è stata in molti progetti sostituita dalle pull request, che sono richieste di integrazione delle modifiche presentate attraverso un'interfaccia web. 
 Le pull request offrono una serie di vantaggi rispetto alle richieste via email, come una maggiore trasparenza del processo di integrazione, una maggiore efficienza e una maggiore facilità di utilizzo.
@@ -247,4 +251,4 @@ Matteo Mangioni (18):
  create mode 100644 assets/09_nullObject-valori-non-assenti.png
 ```
 
-Questo modello è molto più _peer to peer_ delle pull request proposte dai sistemi semi-centralizzati spiegati in seguito.
+Questo modello è un metodo basilare per risolvere i problemi di integrazione ma troppo basilare ancora. È un sistema molto più _peer to peer_, quindi troppo limitato nei grossi progetti _Open Source_ rispetto alle pull request proposte dai sistemi semi-centralizzati spiegati in seguito.

src/06_git-workflow/02_hosting-centralizzato.md

@@ -7,13 +7,16 @@ Inoltre, molti servizi di hosting centralizzati offrono funzionalità aggiuntive
 
 ## Fork
 
-Il "fork" di un repository Git è una __copia del repository originale__ che viene creata su un account di hosting diverso dal proprietario originale. 
-Questo permette a un altro sviluppatore di creare una copia del repository e di lavorare su di essa senza influire sul lavoro del proprietario originale e __senza la sua autorizzazione__. 
+Il "fork" di un repository Git è una __copia del repository originale__ che viene creata su un account di hosting diverso dal proprietario originale. Inizialmente era un operazione "negativa" poichè lascia intendere una diatriba nella direzione dello sviluppo di un software e quindi la nascita di __due diversi cammini__ e lo split del team che ci lavorava.
+
+Oggi invece è visto come aspetto positvo perchè permette a un altro sviluppatore di creare una copia del repository e di lavorare su di essa senza influire sul lavoro del proprietario originale e __senza la sua autorizzazione__. 
 È possibile quindi mantenere una _connessione_ tra i due repository e condividere facilmente le modifiche apportate.
 
 La maggioranza delle piattaforme di hosting centralizzato __ottimizza la condivisione dello spazio degli oggetti__, utilizzando un'unica _repository fisica_ per tutti i fork.
 Tuttavia, questo può comportare alcune problematiche di sicurezza, come ad esempio la difficoltà per la piattaforma di stabilire in quale fork si trova un determinato oggetto in caso di conflitto o la possibilità che un utente malintenzionato possa modificare o eliminare accidentalmente oggetti di altri fork. 
-Per questo motivo, è importante che le piattaforme implementino __misure di sicurezza adeguate__ per proteggere i dati dei fork e garantire la tracciabilità delle modifiche ([esempio sul kernel Linux](https://github.com/torvalds/linux/commit/b4061a10fc29010a610ff2b5b20160d7335e69bf)). 
+Per questo motivo, è importante che le piattaforme implementino __misure di sicurezza adeguate__ per proteggere i dati dei fork e garantire la tracciabilità delle modifiche ([esempio sul kernel Linux](https://github.com/torvalds/linux/commit/b4061a10fc29010a610ff2b5b20160d7335e69bf)).
+
+I vari fork poi non sono tutti legati tra di loro ma lo sono solo al loro "_padre_" iniziale, quindi va tenuto conto di questo aspetto durante la condivisione delle varie modifiche effettuate e le possibili evoluzioni diverse dei progetti.
 
 ## Review / Pull request
 

src/06_git-workflow/03_gerrit.md

 # Gerrit
 
-Gerrit è un __sistema di review__ del codice sviluppato internamente da Google per gestire i progetti interni; si basa sul concetto di "peer review": tutti gli sviluppatori sono autorizzati a fare review delle proposte di modifica di qualsiasi zona di codice.
+Gerrit, prima conosciuto come Mondrian, è un __sistema di review__ del codice sviluppato internamente da Google per gestire i suoi progetti _Open Source_ ormai diventati troppo grandi, come __Android__. Nasce dal numero troppo elevato di pull-request, data la dimensione la grande partecipazione al progetto si basa sul concetto di "peer review": tutti gli sviluppatori sono autorizzati a fare review delle proposte di modifica di qualsiasi zona di codice.
 
 Nel processo di review di Gerrit, i __developer__ possono sottoporre proposte di cambiamento utilizzando un sistema di "patch" che descrive le modifiche apportate al codice. 
 I __reviewer__, ovvero gli altri sviluppatori del progetto, possono quindi esaminare le patch e decidere se accettarle o rifiutarle. 
-Una volta che una patch ha ricevuto un numero sufficiente di review positivi, viene automaticamente integrata nel __repository principale autoritativo__   in cui tutti hanno accesso in sola lettura.
+Una volta che una patch ha ricevuto un numero sufficiente di review positivi, viene automaticamente integrata nel __repository principale autoritativo__ in cui tutti hanno accesso in sola lettura.
 
 Gerrit obbliga a strutturare le modifiche (_changeset_) in un unico commit (tecnica _squash_) al momento dell'accettazione. 
-Ciò significa che tutte le modifiche apportate devono essere fuse in un unico commit, in modo da rendere più facile la gestione del repository. 
+Ciò significa che tutte le modifiche apportate devono essere fuse in un unico commit, in modo da rendere più facile la gestione del repository e per evitare la nascita di troppi rami. 
 Al momento della review, invece, le modifiche rimangono separate in versioni singole, ovvero ogni modifica viene presentata come un commit separato, in modo che i reviewer possano esaminarle più facilmente.
 
+Due figure importanti devono fare parte di questo processo:
+
 ## Verifier
 
 Il verifier è uno strumento o un processo che viene utilizzato in Gerrit per verificare che le modifiche proposte siano corrette e funzionino come dovrebbero. 
 In particolare, il verifier scarica la patch, la compila, esegue i test e controlla che ci siano tutte le funzioni necessarie. 
 Se il verifier rileva dei problemi, può segnalarli al team di sviluppo perché vengano corretti prima che la patch venga accettata.
 
+È un processo semplice quindi può essere anche automatizzato o eseguito da utenti poco esperti o riconosciuti.
+
 Una volta terminato il proprio processo, approva le modifiche votandole positivamente.
 Solitamente sono necessari 1 o 2 voti per procedere.
 
 ## Approver
 
 Una volta verificata, una proposta di modifiche deve essere anche approvata. 
-L'approvatore deve determinare la risposta alle seguenti domande riguardo la proposta di modifiche:
+L'approvatore, che dovrà avere una certa esperienza, dato che non si tratta più di un lavoro meccanico ma "_filosofico_" deve determinare la risposta alle seguenti domande riguardo la proposta di modifiche:
 - _è valida per lo scopo del progetto?_
 - _è valida per l'architettura del progetto?_
 - _introduce nuove falle nel design che potrebbero causare problemi in futuro?_
@@ -31,3 +35,14 @@ L'approvatore deve determinare la risposta alle seguenti domande riguardo la pro
 - _introduce rischi per la sicurezza o la stabilità?_
 
 Se l'approver ritiene che la proposta di modifiche sia valida, può approvarla scrivendo "LGTM" (acronimo di _"Looks Good To Me"_) nei commenti della pull request.
+
+Esiste poi una gerarchia di approver, data dalla loro esperienza e contributo, i cui voti avranno valori diversi, in questo modo è possibile fare una review distribuita migliore,
+
+## Aggiungere parte sul funzionamento di Gerrit (con le due repo, slide non ancora caricate)
+
+- gerrit è come se fosse composto da due repo
+- su una solo fetch, solo lettura
+- sulla seconda push
+- i reviewer usano la seconda, e la prima viene aggioranta dopo la review
+- posso automattizare build e testing
+- test non dimostrano la correttezza assoluta, mostrano solo quando malfunziona, è un approccio ottimistico

src/06_git-workflow/04_strumenti-opensource/01_build-automation.md

@@ -6,7 +6,7 @@ Inoltre, la build automation garantisce una maggiore qualità e coerenza del sof
 
 ## `make`
 
-`make` è uno strumento di build automation che viene utilizzato per automatizzare il processo di compilazione di un progetto. 
+`make` è uno strumento di build automation che viene utilizzato per automatizzare il processo di compilazione di un progetto, infatti non è altro che uno script di comandi _shell_. 
 In particolare, `make` viene utilizzato per specificare come ottenere determinati _targets_ (obiettivi), ovvero file o azioni che devono essere eseguite, partendo dal codice sorgente. 
 Ad esempio, in un progetto di sviluppo software, un _target_ potrebbe essere il file eseguibile del programma, che viene ottenuto compilando il codice sorgente. 
 `make` segue la filosofia _pipeline_, ovvero prevede l'utilizzo di singoli comandi semplici concatenati per svolgere compiti più complessi.
@@ -28,9 +28,9 @@ hellomake: hellomake.c hellofunc.o
 
 Nell'esempio, se il _target_ hellomake (definito dai file `hellomake.c` e `hellofunc.o`) è stato aggiornato, occorre ricompilarlo utilizzando i comandi sotto.
 
-Tuttavia, make lavora a un livello molto basso, il che può rendere facile commettere errori durante la sua configurazione e utilizzo.
+Tuttavia, make lavora a un livello molto basso, il che può rendere facile commettere errori durante la sua configurazione e utilizzo, quindi deve essere reso il più __parametrico__ possibile.
 
-Non c'è portabilità tra macchine (ambienti) diverse.
+Nonostante la paremetrizzazione _non c'è portabilità_ tra macchine diverse, sia per architettura che per sistema operativo.
 
 ### `Makefile`
 
@@ -93,6 +93,8 @@ Esempio di un build file:
 </project>
 ```
 
+Ovviamente è un progetto scritto in Java pensato per compilare codice Java che poi girerà sulla JVM, quindi ottimo in questo caso specifico perchè risolve i problemi dovuti ad avere macchine con diversi ambienti. Ma è anche estremamente limitante, infatti è complesso utilizzarlo con altri linguaggi.
+
 ## Gradle
 
 Gradle è uno strumento di build automation che utilizza le repository Maven come punto di accesso alle librerie di terze parti. 
@@ -100,7 +102,7 @@ Maven è una piattaforma di gestione delle dipendenze e della build automation p
 Le repository Maven sono archivi online che contengono librerie Java, plugin e altri componenti utilizzati nella build di progetti Java. 
 Gradle utilizza queste repository per cercare e scaricare le librerie di cui ha bisogno per eseguire la build del progetto.
 
-Gradle, che supporta Groovy o Kotlin come linguaggi di scripting, adotta un approccio dichiarativo e fortemente basato su convenzioni. 
+Gradle è pur sempre java oriented, ma meno di ANT, infatti supporta Groovy o Kotlin come linguaggi di scripting, che non sono precompilati a bytecode e adotta un approccio dichiarativo e fortemente basato su convenzioni. 
 Ciò significa che tutto ciò che è già stato definito come standard non deve essere ridichiarato. 
 Inoltre, Gradle definisce un linguaggio specifico per la gestione delle dipendenze e permette di creare build multi-progetto.
 
@@ -109,7 +111,7 @@ Gradle scala bene in complessità: permette di fare cose semplici senza usare le
 
 ### Plugin
 
-I plugin servono per trattare tool, situazioni, linguaggi definendo task e regole per lavorare più facilmente.
+I plugin servono per trattare tool, situazioni, linguaggi definendo task e regole per lavorare più facilmente, ci permettono di creare catene di task legate tra di loro e vedere le dipendenze del caso specifico, oppure di far girare solo determinati gruppi di test che mi interessano.
 
 Il plugin _Java_ definisce:
 - una serie di __sourceSet__, ovvero dove è presente il codice e le risorse. Principalmente sono:

src/06_git-workflow/04_strumenti-opensource/02_bug-tracking.md

@@ -4,12 +4,16 @@ Il bug tracking è stato reso necessario nel mondo open source per via della num
 
 Inoltre, per gestire le segnalazioni di bug nell'ambito dello sviluppo open source, esistono diversi strumenti come git-bug, BugZilla, Scarab, GNATS, BugManager e Mantis.
 
-## Bug workflow
+Questi tool guideranno, anche gli utenti non esperti, nel dichiararli,creano un __database__ dei bug che ci permetterà di evitare segnalazioni multiple per lo stesso baco e semplifica la vista, l'organizzazione e la comunicazione del lavoro a riguardo.
+
+## Bug workflow e ciclo di vitaa
 
 ![Bug workflow](/assets/06_bug-workflow.png)
 
 L'obiettivo del bug tracking è avere più informazioni possibili su ogni bug per saperli riprodurre e quindi arrivare a una soluzione.
 
+Ogni bug quindi avrà un suo ciclo di vita, descritto nell'immagine, che potrà intraprendere diversi percorsi.
+
 È importante verificare i bug una volta che l'_issue_ è stato aperto, in modo da poter confermare la sua esistenza e la completezza delle informazioni fornite.
 
 Un _issue_ è un problema o una richiesta di funzionalità segnalata all'interno di un progetto di software. 
@@ -22,3 +26,5 @@ Ci sono diversi modi per cui può essere chiuso un bug:
 - __can't reproduce__: non è stato possibile riprodurre il bug, ovvero che non è stato possibile ottenere lo stesso risultato o il comportamento segnalato dal bug. Ciò può essere dovuto a una mancanza di dettagli o a un errore nella segnalazione del bug stesso;
 - __fixed__: il bug è stato fixato;
 vs __fix verified__: il fix è stato integrato in una release passando tutti gli step di verifica.
+
+I tool di bug tracking sono sempre più integrati negli strumenti di versioning, quindi il baco viene legato a un commit in particolare e da questo possiamo ricavare la sua storia e la sua evoluzione durante la sua risoluzione in base alle sue transizioni di stato e ai commenti dei commit. Ovviamente questo processo si complica se saranno presentid diversi rami nel nostro processo.
\ No newline at end of file

src/06_git-workflow/05_unified-process.md

+# Unified Process
+
+Conosciuto nelle sue versioni commerciali anche come:
+- __USDP__ Unified Software Development Process
+- __RUP__ Rational Unified Process
+
+È un modello di processo definitori dagli stessi creatori di UML, quindi ottimo da utilizzare in contemporanea.
+
+In base al livello di astrazione nel quale ci troviamo è un meta-modello che può essere defininito come:
+
+- __Sequenziale__: Dato che si compone di 4 nuove fasi che vengono ripetute in sequenza.
+- __Iterativo__: Infatti ognuna delle 4 fasi è composta da sotto-fasi che vengono eseguite in successione
+- __Incrementale__: Poichè alla fine delle 4 fasi si consegna un progretto e poi si riprende dalla prima per continuare il suo sviluppo.
+
+## DA AGGIUNGERE IMMAGINE SULLE SLIDE DELLE VARIE FASI
+
+Le fasi in questo modello non sono isolate, bensì ci sarano delle predominanze. Saranno comunque presenti delle __mile-stone__ da raggiungere per poter permettere di scandire il tempo in base alle azioni svolte.
+
+Lo schema permette di capire la complessità do questo modello e il continuo __over-lapping__ necessario. Le attività sono tutte troppo interesecanti tra loro, per questo motivo è definito come __meta-modello__, infatti non potrà essere seguito alla lettera ma dovrà essere configurato in base alle esigenze del progetto e del team di sviluppo. Può essere addirittura reso _agile_ con le opportune modifiche.
\ No newline at end of file