No results found
di Yefry Figueroa
La stesura di software e firmware non è limitata alla conoscenza e all’utilizzo dei linguaggi di programmazione, al debug e all’ottimizzazione del codice: coinvolge e ha sempre coinvolto anche la gestione delle versioni.
Proprio il versioning è diventato, con il lavoro in team e la collaborazione in rete, un problema rilevante, al quale sono state fornite alcune soluzioni, tra le quali spicca Git, che è un motore di versioning gestibile da interfacce grafiche utente (GUI) sia in locale, sia su piattaforme web, una delle quali è GitLab.
In questo tutorial familiarizzeremo con Git affrontando nell’ordine i seguenti argomenti:
Per capire che cos’è GitLab è necessario innanzitutto spiegare che cos’è Git; una volta che ciò risulterà chiaro arriveremo quindi a spiegare che cosa sia la piattaforma GitLab (open source GitHub) e a conoscere le sue caratteristiche principali, per poi concludere con una breve demo dove faremo insieme i primi passi nel mondo di Git.
In linea generale si chiama sistema di controllo di versione (o versioning oppure VCS, acronimo di Version Control Systems) tutto ciò che permette di gestire le versioni, modifiche, release di software e firmware; questo, allo scopo sia di identificare cronologicamente le modifiche, sia di annullare quelle che hanno determinato un malfunzionamento o che sono divenute superflue nel tempo, sia di rintracciare l’autore nel caso di progetto al quale lavorano più sviluppatori.
Dunque, un sistema di versioning:
In commercio esistono vari software per il versioning, ma ci soffermeremo su Git perché, a differenza dei competitor, considera i propri dati come una serie di "instantanee" di un mini file-system. Ad esempio, prima dell’arrivo di Git, per poter sviluppare o modificare un progetto una delle soluzioni ogni giorno era creare una copia della cartella del progetto nominandola con la data, il che, in progetti protratti per lunghi periodi di tempo, significava doversi districare in tantissime cartelle da numerare a mano in modo progressivo. Tale onere diveniva ancor più pesante se al progetto si lavorara in team, giacché alla numerazione progressiva andava affiancata la correlazione con lo sviluppatore.
Git (di seguito ne trovate il logo ufficiale) è un software di controllo di versione che permette ad ogni utente (client) di fare anche da server per se stesso; inoltre possiede una copia locale del repository. Git è il motore della piattaforma GitLab, ossia il suo cuore pulsante.
Git è stato creato da Linus Torvalds, autore del primo kernel di Linux e coordinatore del progetto di sviluppo dello stesso.
Git è un sistema di controllo delle versioni distribuito, di utilizzo gratuito ed è open source, veloce e sicuro (proprio perché è un sistema distribuito); costituisce inoltre un ottimo supporto allo sviluppo non-lineare, garantisce la portabilità (funziona su sistemi operativi MacOs, Linux e Windows) e permette la gestione efficiente di grandi progetti.
Git funziona a riga di comando, perciò per renderne l’utilizzo più agevole è conveniente ricorrere a un’interfaccia grafica che semplifichi l’uso dei comandi; l'interfaccia può anche essere implementata in un servizio web.
Tre concetti fondamentali di Git, che ricorreranno in questo tutorial, sono gli snapshot, i commit, i repository e i branch: analizziamoli insieme.
Gli snapshot (istantanee) sono il modo in cui git mantiene traccia della cronologia del tuo codice; uno snapshot essenzialmente registra lo stato attuale di tutti i file in un dato momento.
Con Git decidi tu quando creare uno snapshot e su quali file ed hai sempre la possibilità di andare indietro a rileggere uno snapshot precedente (ossia una versione) per ricercare un bug o effettuare o rimuovere una modifica al codice.
Il commit è, in Git, l’azione con la quale creiamo uno snapshot; i commit rappresentano il modo in cui si “salvano” le modifiche fatte al codice. Di seguito trovate un esempio di commit.
Ma che cos’è esattamente un commit? Ebbene, il commit corrisponde al salvataggio di uno o più file sul repository; è quindi giunto il momento di spiegare che cos’è quest’ultimo.
Letteralmente tradotto in deposito o magazzino (ma anche contenitore, se vogliamo) il repository è una collezione di tutti i file, con in evidenza la loro cronologia e l’history dei commit. La parola repository indica un archivio ordinato dove sono raccolti i file del progetto.
Il repository può risiedere su un computer locale o su un server remoto come, è nel caso di GitLab.
In senso generale, un repository è un’area di memoria di massa accessibile da un’interfaccia utente, che riporta un gruppo di file e può essere condiviso, come nel caso di GitHub, dal quale tramite web scarichiamo software, firmware ecc.
Le principali funzionalità connesse ai repository sono:
Letteralmente tradotto in “ramo”, il branch è una branca o diramazione nella struttura ad albero del repository, come mostrato nella figura sottostante.
Git archivia i file e li tiene ordinati ad albero, evidenziando come sia facile ed intuitivo poter vedere le differenze di un file (o progetto) dopo che è stato modificato dal primo salvataggio “commit”.
Va ricordato che:
Quindi si può affermare che dei commit tra loro collegati risiedono in uno o più branch, all’interno di un repository. Ciò detto, abbiamo finalmente tutte le basi per riprendere la domanda iniziale e darle una risposta.
Si tratta di una piattaforma on-line basata su Git, che facilita lo sviluppo collaborativo di firmware e software, semplifica il lavoro distribuito mettendo a disposizione una piattaforma centralizzata; sostanzialmente GitLab è una piattaforma che consente di utilizzare il “motore” di versioning Git, analogamente a quanto avviene sulla piattaforma GitHub. Prima di procedere è opportuna una precisazione, visto che spesso si fa molta confusione: GitHub è nata per ospitare progetti sviluppati con Git; offre spazio a pagamento per progetti privati e spazio gratuito per progetti condivisi open source.
GitLab è invece un prodotto free. GitLab è disponibile in due versioni:
La prima consente di installare GitLab su un proprio server locale o su un servizio di cloud privato e consente il pieno controllo della piattaforma e dei propri dati: è l’ideale per le aziende che necessitano di accedere esclusivamente e in ogni momento ai dati dei propri progetti, giacché offre più sicurezza dagli attacchi esterni e velocità di accesso, data l’esclusività dell’utilizzo del server. Tale versione è totalmente gratuita.
La versione SaaS (Software as a Service), invece, risiede tutta sulla soluzione cloud gitlab.com, file compresi. A differenza di piattaforme on-line come GitHub e servizi quali Bit Bucket (basato anch’esso su Git), su GitLab abbiamo:
Gitlab è una piattaforma con focus particolare in ambito DevOps, offrendo:
In informatica DevOps (dalla contrazione dei termini Development e operations, inteso come deployment o rilascio) è una metodologia di sviluppo del software che punta alla comunicazione, collaborazione e integrazione tra sviluppatori e addetti alle operations dell'information technology. DevOps vuole rispondere all'interdipendenza tra sviluppo software e IT operations, puntando ad aiutare a sviluppare in modo più rapido ed efficiente prodotti e servizi software.
Proviamo a vedere questi concetti in pratica innanzitutto esplorando l’interfaccia utente, che appare come mostrato nella figura sottostante. Va ricordato che in GitLab può essere richiesto l'utilizzo della riga di comando, ossia di Git nella sua interfaccia nativa.
Qui trovate la finestra principale con in alto la toolbar e a sinistra il riquadro delle attività, che nello specifico è aperto sui file del repository interessato (Files).
Facendo clic su un file è possibile vedere le relative branch.
Cliccando su Commits è possibile vedere i commit del repository interessato, mentre su Branches apriamo la visualizzazione delle branch.
La funzione commit consente di individuare ciascun utente che ha lavorato al repository e vedere che cosa ha fatto, con in evidenza le operazioni effettuate, vale a dire aggiunta/cancellazione di righe di codice.
Per poter utilizzare GitLab occorre andare al sito di riferimento www.gitlab.com e qui registrarsi, creando il proprio account secondo le istruzioni fornite passo-passo dal sito.
Una volta in possesso dell’account, vediamo un esempio che mostra come creare un nuovo repository: si parte dalla schermata iniziale dei progetti, cui si accede facendo clic sulla voce Projects della toolbar. Nella finestra, mostrata nell’immagine seguente, troviamo quattro opzioni sotto forma di icone.
Per creare un nuovo repository facciamo clic su Create a project, anche se conviene prima creare un gruppo (comando Create a group) che consiste nel definire un contenitore nel quale troveranno posto più progetti e verranno definiti sia gli utenti che vi lavoreranno, sia le loro autorizzazioni.
Torniamo alla creazione del progetto e, nella finestra che si apre con il comando Create a project possiamo scegliere fra tre opzioni, ognuna associata a un tab: Blank project se vogliamo un nuovo progetto vuoto, Create from template se preferiamo affidarci a un modello (template) e Import Project se intendiamo aprire un lavoro esistente. Vedete le tre opzioni nella schermata seguente.
Nel caso di Blank project scriviamo il nome del progetto nella casella Project name; possiamo eventualmente aggiungere una descrizione nel riquadro Project description, ma non è necessario.
Nella sezione Visibility level possiamo definire il grado di protezione del progetto, selezionando il pulsante d’opzione desiderato, ossia:
Quest’ultimo è il caso di progetti open cui possono contribuire tutti. Quanto a Internal, è una soluzione ideale se GitLab è installato su una piattaforma "interna" ossia su un server o cloud privato aziendale, allorché il progetto potrà essere accessibile da tutti gli utenti dell'azienda e non si restringerà la cerchia delle persone che vi potranno lavorare.
Nel caso di Create from template potete scegliere fra i template disponibili. Invece se optate per l’importazione di un progetto, fate clic su Import project e potete scegliere la fonte da cui effettuare l’importazione, che può essere un servizio di hosting o un servizio web come GitHub o Bitbucket.
Nel caso specifico, l’esempio che vi proponiamo riguarda la creazione di un Blog chiamato Bambino Felice e di tutti i relativi file in GitLab; siccome si tratta di un nuovo progetto, quindi nel tab Blank project scriviamo il nome del progetto nella casella Project name, ossia bambino-felice e se vogliamo, nel riquadro Project description mettiamo una descrizione.
Nella sezione Visibility level possiamo definire il grado di protezione del progetto.
Indipendentemente dalla scelta, il progetto si crea con il pulsante verde Create Project. Nella finestra che si apre, che è quella del progetto, viene comunicato che il progetto è vuoto e possiamo quindi iniziare a costruirlo; nella stessa schermata sono elencati, divisi per categoria, tutti i comandi disponibili (li troviamo nella zona a sinistra della finestra) per la creazione ed è presente il pulsante New File.
I comandi Global setup servono a configurare l’ambiente nel complesso (in pratica sono quelli riguardanti l'utente che crea il repository , mentre quelli in Create a new repository riguardano la creazione di repository da zero; Existing folder contiene i comandi per la gestione da cartelle esistenti ecc.
È possibile impostare GitLab e costruire o gestire i repository da linea di comando, aprendo una finestra (bash per Linux e MacOS dalla versione X in poi, ovvero il cmd di Windows) dove scrivere i comandi con la sintassi indicata (vedere la figura seguente); in pratica basta copiare i comandi che ci interessano e introdurre i parametri desiderati, come visibile nella figura sottostante, che riporta la finestra della CLI (riga di comando) dove stiamo operando.
I comandi introdotti da terminale vengono eseguiti e possono dare luogo ad operazioni e risposte contenenti l'help in linea.
La prima cosa da fare è creare una directory (cartella) per il repository (si impartendo il comando mkdir), quindi creare il file README, che dovrà contenere le prime cose che appariranno a chi aprirà il repository. Creando il file README si apre automaticamente l'editor di testo nel quale scrivere il contenuto, salvando il quale si torna alla finestra della riga di comando.
Fatto ciò bisogna inizializzare il progetto basato su Git e ciò viene fatto impartendo il comando git init, cui il sistema risponderà confermando che è stato inizializzato il repository ecc.
È possibile automatizzare il processo di creazione del repository lanciando, dal link AutoDevOps (Beta), AutoDevOps: questo tool, sulla base della configurazione CI/CD predefinita, costruirà, testerà e distribuirà l’applicazione in maniera automatica. In questo caso sarà possibile intervenire con le modifiche del caso sull’applicazione creata, per personalizzarla.
Impartendo il comando git status possiamo quindi vedere la situazion e attuale del progetto, che nella figura seguente appare come "nulla sul branch master" e che non riporta alcun file trovato.
Aggiungiamo quindi il file README con il comando git add README.md (per MacOS, ma se usate Windows il nome completo di estensione sarà README.txt).
Se ora impartite il comando git status apparirà, dopo No commits yet, il nome del file README.
Possiamo dunque introdurre la prima "versione" del codice, ossia creare il primo commit da riga di comando: ciò viene ottenuto con il comando git commit -m "testo messaggio", dove -m indica che a seguire, tra virgolette, scriviamo il nome del messaggio, perché ogni commit deve avere associato un messaggio per l'identificazione.
Nella figura seguente il messaggio è "il nostro primo commit".
Premendo il tasto Invio si esegue il comando e il commit viene creato, allorché tornando sulla finestra di GitLab possiamo vedere che per il momento nulla appare, in quanto in riga di comando abbiamo lavorato in locale sul nostro PC ma dobbiamo trasferire tutto in remoto sul server di GitLab; allo scopo, sempre dalla finestra CLI impartiamo il comando git remote add origin seguito dall'URL per trasferirlo sul server remoto GitLab. Tale indirizzo, che poi è il nome del repository che abbiamo creato in locale, potete copiarlo dalla casella HTTPS che si trova nella finestra di GitLab su Overview>Details. Copiatelo e incollatelo dopo git remote add origin, quindi premete Invio. Adesso la schermata di GitLab appare aggiornata, come si vede nella figura seguente.
Tornando alla finestra della riga di comando, impartite il comango git push -u origin master per eseguire il push, che praticamente inoltra (spinge) tutto il contenuto in locale sul server remoto di GitLab (lo vedete nella finestra CLI della figura precedente).
Poco dopo, dalla finestra di lavoro di GitLab, sempre in Overview>Details, vedrete aggiornarsi la situazione del repository, con indicata la cronologia dei commit, come nell'immagine seguente, dove si vedono i file caricati nel branch master.
Adesso facciamo clic nella sezione a sinistra della finestra di lavoro sulla voce Repository e quindi, nel menu che si apre, su Branches, quindi creiamo un nuovo branch facendo clic sul pulsante verde New branch che troviamo a destra dello schermo; così facendo accediamo alla finestra riportata nell'immagine seguente, dove scriveremo il nome del nuovo branch, cui daremo il nome "staging" e provvederemo alla creazione facendo clic sul pulsante Create branch. Il nuovo branch sarà creato a partire dal master, come indicato nella casella Create from.
Vediamo adesso una interessante ed utile funzione di GitLab che è rappresentata dagli Issues (compiti): si tratta di strumenti molto utili quando a un progetto si lavora in team, giacché consente di assegnare o semplicemente ricordare dei compiti.
Vediamo come si esegue un issue: nella solita sezione a sinistra facciamo clic sulla voce Issues e accediamo alla relativa finestra di lavoro; l'esercitazione che proponiamo consiste nel creare una nota per un utente che ricordi di eseguire un compito consistente in una modifica in un branch, del nostro solito blog Bambino felice. Questa modifica verrà introdotta nel branch staging.
Nella finestra Issues facciamo clic su New Issue e in essa (vedere figura seguente) scriviamo il nome dell'Issue nella casella Title; il titolo è la sostanza della modifica, che nello specifico è "cambiare bambino in mamma" e, come descritto nella casella Description (che andiamo a compilare) il cambiamento verrà apportato nel file README.
In basso nella finestra possiamo decidere chi sarà il destinatario di questo Issue, ovvero se renderlo riservato a noi (confidential). Cliccando sul pulsante Submit Issue in fondo alla pagina verrà inviato l'Issue.
Si torna, così, alla finestra Issue e da qui vediamo ora i due branch, che però non saranno visibili in locale sul PC; infatti qui, riaprendo la finestra della riga di comando, troviamo solo il primo branch perché l'aggiunta è stata fatta sul server remoto.
Per aggiornare la situazione occorre impartire il comando "git pull", che dige a GitLab di tirarsi dietro, ovvero caricare, sul computer locale le ultime modifiche memorizzate nel server remoto.
L'immagine qui di seguito illustra il risultato del pull, che sostanzialmente comunica che non c'è alcun nuovo file ma che c'è un nuovo branch.
Ora per eseguire l'Issue bisogna spostarsi sul branch staging; ciò si effettua impartendo il comando "git checkout staging" (git checkout indica a GitLab di passare da un branch all'altro, ossia sul branch di cui viene scritto il nome di seguito).
A questo punto, sempre dalla finestra della riga di comando apriamo il file README ed effettuiamo la modifica testuale, quindi chiudiamo lo stesso README, non prima di averlo salvato.
Tornati sulla CLI, ripetiamo le operazioni già viste per aggiungere il file modificato, ovvero impartiamo il comando git add README.txt (git add README.md per MacOS).
Se ora impartite il comando git status apparirà, il nome del file README aggiornato.
A questo punto salviamo il commit (vedere immagine seguente) con il comando git commit -m "cambiato bambino per mamma" e con Invio lo eseguiamo.
A questo punto impartiamo il comando git push -u staging e lo schermo ci mostra il risultato del push; inoltre viene inviata la modifica al server remoto GitLab. Possiamo verificare che ciò sia avvenuto tornando sulla pagina di GitLab e verificando che nel branch master vi sia il blog bambino felice (come nell'immagine che segue),
mentre che sul branch staging ci sia il blog mamma felice (immagine seguente).
A questo punto possiamo chiudere l'Issue, eventualmente aggiungendo messaggi per gli altri componenti del team.
Passiamo adesso a un'altra funzione di GitLab che è Container Registry: essa viene installata automaticamente nelle versioni recenti (dal 2017) di GitLab sia in remoto che in locale (in quest’ultimo caso sono richoieste alcune configurazioni specifiche del PC su cui GitLab funziona). La finestra di Container Registry è mostrata nell’immagine seguente.
Container Registry è una funzione che serve a gestire le immagini di Docker e l’interazione con Docker, ovvero con tale tool installato, ongi progetto in GitLab potrà avere uno spazio in Docker.
Passiamo oltre e vediamo un’altra funzione, che è la CI/CD, contenente alcuni tool per la Continuos Integration, accessibili dal menu contestuale che si apre quando si fa cli c su CI/CD.
Come vedete nel menu laterale, c’è poi la possibilità di creare delle Wiki per il proprio team o condivise con tutti gli utenti GitLab, degli Snippet ecc. Ciascuna funzione è accessibile dalla specifica voce di menu.
Altra funzione interessante di GitLab è la possibilità di eseguire un merge delle modifiche effettuate da vari utenti, che, aprendo un branch e quindi un progetto, verranno evidenziate con vari colori e distinte per autore. Se portiamo il puntatore del mouse sul nome del file modificato e facciamo clic, le modifiche appaiono in giallo; almeno, quelle da noi effettuate.
Questo metodo si chiama “merge” e corrisponde al confronto e alla segnalazione visiva delle differenze tra due file. Consente di sapere che modifiche sono state fatte da quando abbiamo “committato” ad oggi.
Per avviare il merge, una volta aperta la finestra del branch basta fare clic sul pulsante Merge request, quindi procedere. Le merge request sono peraltro riportate nel menu contenuto nel riquadro a sinistra della schermata di lavoro di GitLab.
La schermata ci permette di vedere le differenze tra il progetto “committato” e il progetto che abbiamo modificato. Vengono visualizzati tutti i dati da quando abbiamo fatto il primo commit, quindi non si perde neanche una riga di codice.
Accanto alle modifiche può apparire un punto esclamativo: con esso Git controlla i cambiamenti effettuati e li segnala.
Per ogni progetto è disponibile una struttura ad “albero” che consente di ripercorrere le modifiche attraverso i commit, fino a tornare al primo commit.
È anche possibile cancellare i branch sottoposti a merge (pulsante Delete merged branches).
