GitLab


GitLab (gitlab.com) è un sistema di controllo versione GIT, basato su interfaccia web in cui è possibile utilizzare, oltre al classico controllo di versione, un wiki per la gestione della documentazione e un issues tracking per il project management.

GitLab è disponibile in 2 versioni, Community Edition e Enterprise Edition e si differenziano per numero di funzionalità e supporto, qua potete trovare la comparazione delle versioni. GitLab si può installare all’interno della propria infrastruttura privata o utilizzare la classica modalità SaaS direttamente online, quest’ultima offre il vantaggio di avere a disposizione illimitati repository privati totalmente free.

GitLab CI è un tool integrato in GitLab e contribuisce a migliorare le fasi di deployment in ambienti di testing, staging e produzione utilizzando degli speciali trigger in grado di eseguire il nostro codice nei vari ambienti oppure sfruttando le capacità dei Docker Container per l’esecuzione delle test unit.

La caratteristica principale di GitLab CI è quella di poter eseguire i deployment in base ai diversi ambienti collegandoli  ai vari branch del repository (es. testing, staging, production) trasformando il tool da sistema di Continuous Integration a Continuous Deployment.

  • Continuos Integration

    Il ciclo di vita di un’applicazione inizia dall’esecuzione di tasks da parte del team di sviluppo, ad ogni task completato l’applicazione subisce una variazione che si dovrà integrare con tutte le altre variazioni introdotte dai componenti del team durante lo stesso intervallo di tempo. Il completamento di un task (Done) non riguarda solo scrivere il nuovo codice sorgente o farne delle variazioni più o meno importanti ma è avere la certezza che il task superi una serie di requisiti necessari per dichiararlo come sicuramente completato (DONE-done).
  • Continuos Delivery

    Quando il codice soddisfa i requisiti per essere definito sicuramente completato (DONE-done) o sicuramente pronto (READY-ready) si procede attraversando la pipeline con il rilascio del codice sorgente da un ambiente unicamente di test ad un altro più evoluto in termini di architettura (continuity), ad esempio dopo il server di testing (fisico, virtuale o docker) si rilascia il codice su un server di staging o Q/A , sincronizzando il branch dedicato al contesto di utilizzo oppure il master branch su un sistema production-like. In questa fase una nuova release è disponibile e accessibile in base ai requisiti di utilizzo: staging, beta testing, Q/A team, front-end test, A/B testing, ecc.
  • Continuos Deployment

    Provate a chiedere ad un DevOps la differenza tra Continuos Delivery e Continuos Deployment, se provate a chiederlo a più di uno avrete con buona probabilità 2 o più risposte diverse, le scuole di pensiero sulle strategie di continuity differenziano i vari cicli mentre altre li accomunano. Come per altri metodi, le procedure e i processi del metodo si modellano sulle necessità di un gruppo organizzato e iterativo, il nostro è quello di concludere la distribuzione sui sistemi di produzione con un deployment automatizzato sui nodi dedicati all’aggiornamento di versione, consigliando ed integrando sempre la modalità Blue Green.

Pipeline


Definire e seguire una pipeline consente di avere il controllo completo dei processi di deployment, dove gli unici interventi necessari sono quelli relativi agli eventuali errori rilevati durante l’esecuzione delle procedure che, in casi estremi, dispongono di procedure di rollback in grado ti riportare l’accesso verso i servizi ad una versione precedente.