GitLab ###### GitLab è uno degli strumenti più potenti e sottovalutati che abbiamo adottato nel flusso di lavoro qui in Monk. Questa pagina ha l'obiettivo di raccogliere alcune best practice e consigli per tutti coloro i quali si siano trovati a dover gestire progetti complessi, sopratutto lavorando in team, con la necessità di continui rilasci e con prodotti che fossero il più possibile stabili. (D'ora in poi prenderemo come esempio questo progetto creato adhoc: https://git.webmonks.org/alessio.arsuffi/testdocs) Branch Protetti =============== Questa funzionalità proibisce ad alcuni utenti di poter accettare una merge request, di fare force push e di cancellare il branch. Perchè proteggere un branch? Per non correre rischio di vedere mergiate funzionalità non abbastanza testate o comunque errate in development/master. Navighiamo tramite il menu a sinistra alla sezione `Settings`, poi `Repository` .. image:: protected-branch-1.png :height: 250px Espandiamo la sezione `Protected Branches`, inseriamo develop e/o master (o il branch che preferite), e nei due parametri sottostanti selezioniamo: - Mantainers (questa impostazione la consiglio in quanto generalmente ci sono pochi mantainers e molti developers) - Mantainers + Developers (stessa opzione di sopra con permesso esteso per i developers) - No one (Utile se avete un branch che rappresenta anche una versione del prodotto che non è possibile patchare) .. image:: protected-branch-2.png :alt: master protetto Per altre info: `protected branches `_ Controlli su Merge Requests =========================== GitLab permette di disabilitare in automatico l'accettazione di una Merge Request qualora la pipeline (ove configurata) non sia passata con successo e/o qualora tutte le discussioni della Merge Request non siano state segnate come risolte. Per poter abilitare questa opzione basta procedere tramite menu laterale alla sezione `Settings` -> `General` -> `Merge requests` -> `Merge checks`. .. image:: merge-checks-1.png :height: 250px Nello specifico: - La prima opzione è utile qualora non vogliate accettare una Merge Request che non faccia passare qualche test automatico, oppure che faccia fallire la build di un pacchetto. - La seconda opzione invece è utile qualora, avviata una discussione su una Merge request, essa non venga dichiarata chiusa (solved) dal reviewer, impedendone di fatto il seguente merge nel branch selezionato. Milestones ========== Molto utile, questa funzione ci permette di creare dei veri e propri `tags`, dove andremo a sviluppare i nostri prodotti. Pensate ad una milestone come "la prossima release del vostro prodotto". Ad esempio, avremo una milestone **1.0.1**, che conterrà tutti i bug fixes della milestone **1.0.0**, ed una **1.1.0** chè conterrà le future nuove feature del prodotto. Per creare una milestone bisogna navigare tramite menu a sinistra nella sezione Issues -> Milestones, cliccare su `New Milestone`, come title possiamo assegnare la prossima versione del nostro prodotto (es: 1.2.5), ed una eventuale descrizione, possiamo inoltre specificare un inizio e fine data di sviluppo, utile per tracciare le priorità o eventuali ritardi. .. image:: milestones.png Come potete vedere, una milestone è anche contenitore di Issues. La **1.0.0** si può chiudere poichè tutte le issues assgnate sono state risolte da una o più merge requests. (Buona norma è taggare anche alla chiusura della milestone). Issues ====== Le issues sono paragonabili a delle task di Odoo. Ci permettono di tracciare bugs, nuovi sviluppi, discussioni, enhancements. Possono essere assegnate a delle persone, possono essere associate a delle milestone come abbiamo visto in precedenza, possiamo fare una stima del tempo globale per lo sviluppo, ma una delle funzionalità più comode di GitLab è sicuramente quella di poter creare un branch e una merge request collegate tra loro dalla stessa issue. Vediamo come: - Selezioniamo una issue tra quelle nella lista sul menu a sinistra, (es: https://git.webmonks.org/alessio.arsuffi/testdocs/issues/1); - Dal dettaglio, selezioniamo la freccetta di fianco al bottone `Create merge request`, si aprirà il seguente menù (vedi immagine sotto); - Selezioniamo il branch dal quale partire (best practice vuole che non partiate MAI da un altro feature branch, io consiglio da Develop in questo caso), se volete potete anche prefissare il nome del branch (es: feature/nomebranch oppure hotfix/nomebranch) secondo le vostre preferenze; .. image:: issue-branch.png :width: 250px Una volta premuto il bottone, verrà creata una Merge request e un branch, ogni commit che andrete ad effettuare per quel branch, sarà tracciato anche nella corrispettiva Merge request, in maniera da avere un tracciamento completo dello sviluppo. Molto comodo anche per fare code review in team. Slack Webhooks ============== È possibile configurare la ricezione di eventi sottoforma di messaggi Slack come i commit effettuati, creazione/commenti di una issue, l'approvazione di una merge request. Navighiamo tramite il menu a sinistra nella sezione `Settings` -> `Integrations` -> selezionate `slack notifications`. Flaggate tutte le opzioni che vi interessano, poi andate qui: https://monk.slack.com/apps/A0F7XDUAZ-incoming-webhooks, premete su `Add to slack` e scegliete il canale dove pubblicare, copiate la URL del webhook .. image:: slack-1.png Riportatelo sul parametro `Webhook` di GitLab. .. image:: slack-2.png Fate click sul bottone verde in basso per salvare, bene, adesso potrete tenere tutto sotto controllo comodamente dal vostro Slack! Chiusura Issue con messaggio di commit ====================================== È possibile chiudure le issues anche tramite un messaggio di commit. (La regex legge solo il formato in lingua inglese). .. code-block:: sh ((?:[Cc]los(?:e[sd]?|ing)|[Ff]ix(?:e[sd]|ing)?|[Rr]esolv(?:e[sd]?|ing)|[Ii]mplement(?:s|ed|ing)?)(:?) +(?:(?:issues? +)?%{issue_ref}(?:(?:, *| +and +)?)|([A-Z][A-Z0-9_]+-\d+))+) Tutti i commit o le merge request che rispettano questa regex, chiuderanno le relative issues quando il commit oppure quando la merge request sono pushati sul `default_branch`. NB: `Related to` segna la issue come relativa di un altra, ma non chiuderà quest'ultima qualora rispettata la condizione sopra. .. image:: merge_request_closes_issue.png Prontuario per la regex: - Close, Closes, Closed, Closing, close, closes, closed, closing - Fix, Fixes, Fixed, Fixing, fix, fixes, fixed, fixing - Resolve, Resolves, Resolved, Resolving, resolve, resolves, resolved, resolving - Implement, Implements, Implemented, Implementing, implement, implements, implemented, implementing Per maggiori dettagli visitate la doc ufficiale di `Gitlab `_.