Piattaforma-OSCAT-GitLab/Casi-d-uso/Dal-primo-commit-al-deploy.md

@@ -7,12 +7,12 @@ Per caricare i sorgenti sul nuovo repository è opportuno effettuare la clone (g
 ![immagine](uploads/bf678ba76814b6c33328af582f93d2bc/immagine.png)
 <br>
 Questa opeazione può essere effettuata sia tramite un client GIT a riga di comando che tramite le funzionalità fornite dai vari IDE.
-Una volta completata l'operazione in locale è disponibile il nuovo repository appena inizializzato e vuoto che può essere gestito a riga di comando oppure importato come progetto in un IDE per una gestione più comoda.
+Una volta completata l'operazione, in locale è disponibile il nuovo repository appena inizializzato e vuoto che può essere gestito a riga di comando oppure importato come progetto in un IDE per un utilizzo più comodo.
 Per aggiungere codice occorre spostarsi sul branch staging e copiare i sorgenti che possono poi essere aggiunti al repository remoto tramite i comandi standard git add/commit/push.
 
 ## Rilascio in ambiente di Certificazione
 
-Una volta effettuata la push si avvia automaticamente la pipeline (che può essere avviata anche manualmente dalla sezione CI/CD) impostata in fase di creazione del progetto e relativa al branch sul quale è stato modificato il sorgente, quindi staging.\
+Una volta effettuata la push, si avvia automaticamente la pipeline (che può essere avviata anche manualmente dalla sezione CI/CD) impostata in fase di creazione del progetto e relativa al branch sul quale è stato modificato il sorgente, quindi staging.\
 Per effettuare il deploy occorre attendere l'esecuzione degli step automatici e avviare tutti i job manuali presenti, quindi build, tag (nel quale viene salvato l'artefatto generato nella sezione "Package Registry" ed effettuato il tag del codice) e deploy.\
 <br>
 ![immagine](uploads/e74bc9f506f896b5edc6a3fe8e588926/immagine.png)
@@ -23,19 +23,19 @@ In seguito al primo deploy può essere richiesta la funzionalità di autodeploy
 ## Modifica al codice e nuovo commit
 
 Nel caso in cui sia necessario effettuare una modifica al codice sorgente, questa può essere apportata sul repository locale (ad esempio tramite IDE) e trasferita sul repository remoto tramite i comandi standard git add/commit/push.\
-In questo modo si avvia nuovamente la pipeline relativa al branch staging come descritto nel paragrafo precedente. E' importante ricordare che per poter rilasciare il nuovo artefatto occorre creare una nuova release e quindi aggiornare il numero di versione che viene usato nello stage tag (e.g. versione contenuta nel pom.xml per i progetti Maven/Java). In caso contrario la pipeline fallisce riportando la causa dell'errore.\
-Non è necessario ad ogni commit completare tutti i passi della pipeline, infatti lo stage tag deve essere avviato solo quando si desidera creare una versione stabile da dispiegare. Altrimenti è possibile effettuare modifiche in serie senza procedere oltre gli step automatici, ad esempio quando si vuole verificare solamente l'analisi SonarQube.\ 
+In questo modo si avvia nuovamente la pipeline relativa al branch staging come descritto nel paragrafo precedente. E' importante ricordare che per poter rilasciare il nuovo artefatto occorre creare una nuova release e quindi aggiornare il numero di versione che viene usato nello stage tag (e.g. versione contenuta nel pom.xml per i progetti Maven/Java). In caso contrario, la pipeline fallisce riportando la causa dell'errore.\
+Non è necessario ad ogni commit completare tutti i passi della pipeline, infatti lo stage tag deve essere avviato solo quando si desidera creare una versione stabile da dispiegare. Altrimenti, è possibile effettuare modifiche senza procedere oltre gli step automatici, ad esempio quando si vuole verificare solamente l'analisi SonarQube.\ 
 Inoltre, non è obbligatorio (ma consigliato) effettuare il rilascio in Certificazione per ogni versione (tag) creata.
 
 ## Rilascio in ambiente di Produzione
 
 Il rilascio in ambiente di Produzione avviene tramite la pipeline relativa al branch master.\
-Una volta creato il tag con le modifiche effettuare sul branch staging occorre aprire una "Merge Request" verso il branch master che può essere chiusa solo da utenti con ruolo Mantainer o Owner.\
+Una volta creato il tag con le modifiche effettuate sul branch staging occorre aprire una "Merge Request" verso il branch master che può essere chiusa solo da utenti con ruolo Mantainer o Owner.\
 <br>
 ![immagine](uploads/b5d79d5d0c8c2b87d5ed4f09a9020001/immagine.png)
 <br>
 Quando la Merge Request viene chiusa e quindi i commit pendenti vengono riportati sul branch master parte la pipeline relativa ad esso.\
 Per effettuare il deploy occorre attendere l'esecuzione degli step automatici e avviare tutti i job manuali presenti, quindi build, tag e deploy.\
-La fase di rilascio inizialmente avviene tramite l'invio di una mail al gestore del servizio che varia a seconda della tipologia di applicazione, e.g. 3-Tier a SCT, Nexus a Supporto Oscat ecc.\
+La fase di rilascio avviene tramite l'invio di una mail al gestore del servizio che varia a seconda della tipologia di applicazione, e.g. 3-Tier a SCT, Nexus a Supporto Oscat ecc.\
 E' possibile, solo per utenti Mantainer o Owner, effettuare anche una push direttamente su branch master, ma questa operazione è riservata a casi particolari. Ad esempio il caso di "hotfix", cioè una modifica da portare in produzione quando sul branch staging sono presenti altre modifiche che non si intende al momento promuovere in Produzione.