Perché la tecnologia collaborativa di GitLab è fondamentale per GitOps: una demo
Un software di collaborazione come GitLab semplifica i flussi di lavoro GitOps. Questo articolo include una demo che illustra come GitLab è in grado di supportare GitOps attraverso efficaci meccanismi di collaborazione.
Per GitOps si intende l'utilizzo di un repository Git come unica fonte di riferimento per tutto il codice necessario alla creazione dell'infrastruttura e al deployment delle applicazioni. Utilizzando come unica fonte di riferimento un sistema di controllo della versione, come Git, i tecnici sono in grado di aggiornare il codice sorgente sottostante per le loro applicazioni in un formato di distribuzione continua.
Il sistema di controllo della versione aiuta a garantire che tutte le attività siano documentate e visibili, mentre un audit trail agevola il rispetto degli standard di conformità. GitOps semplifica il ripristino delle modifiche e centralizza tutte le informazioni più rilevanti in un'unica posizione, in modo da fornire ai team di sviluppo e delle operazioni un'istantanea aggiornata dello stato del progetto in quel preciso momento.
GitLab è un'applicazione singola per l'intero ciclo di vita DevOps e funge da piattaforma di collaborazione che permette alle parti interessate di valutare il processo di produzione del codice. La collaborazione è un aspetto importante del processo GitOps: i gruppi di lavoro coinvolti in ogni fase del ciclo di sviluppo, dai team dell'infrastruttura e di sviluppo ai professionisti della sicurezza e agli stakeholder aziendali, necessitano di un metodo organico per interagire e distribuire il codice in modo rapido ed efficiente.
GitOps non si limita esclusivamente al codice ma include anche altri aspetti importanti come la collaborazione fra i team, mentre GitLab permette a tutti i gruppi di lavoro di operare su un'unica piattaforma.
La demo inclusa nella restante parte dell'articolo illustra come GitLab è in grado di supportare GitOps attraverso efficaci meccanismi di collaborazione. La demo propone esempi di epic e ticket, che sono collegati nelle sezioni successive.
Pianificazione del progetto con le epic
Poiché GitOps si basa sul deployment incentrato sul controllo della versione, il primo passo è definire l'ambito del progetto e identificare gli stakeholder. Successivamente, i membri del team possono condividere qualsiasi altra informazione che potrebbe essere necessaria per realizzare il progetto, ad esempio il processo di programmazione, le modifiche all'Infrastructure as Code e le correzioni da rivedere e di cui eseguire il deployment in produzione.
Dopo aver aperto un'epic nel repository associato, i team possono aggiungere obiettivi e attività nella descrizione. Un'epic consente ai team di monitorare i ticket in diversi progetti e traguardi. Un ticket è il mezzo principale per collaborare allo sviluppo delle idee e pianificare il lavoro in GitLab.
Esempio di epic e ticket
In questa epic di esempio, denominata Scale the Cloud, i team possono visualizzare il processo alla base del ridimensionamento di un cluster Kubernetes in GitLab. Poiché la natura di GitLab è multicloud, i tre diversi ticket presenti nella demo specificano tutte le condizioni necessarie per eseguire il deployment del cluster Kubernetes in ogni ambiente univoco: Azure (AKS), Google (GKE) e Amazon (EKS).
Promozione della collaborazione e della trasparenza con GitLab
Al livello di epic, i team possono riscontrare che il ticket relativo al ridimensionamento all'interno del cluster EKS è già stato risolto. Facendo clic sul ticket, si nota una richiesta di merge che è stata creata dalle attività delineate nel ticket stesso; inoltre, il merge della RM è stato già eseguito.
Per scoprire cosa è cambiato esattamente tra il codice originale e quello attuale, è sufficiente fare clic all'interno della RM. Da qui, i team possono visualizzare tutti i test superati prima/dopo il merge, consultare la cronologia dei commenti per identificare le modifiche e prendere nota di chi ha approvato ed eseguito il merge del codice.
Il ticket relativo al ridimensionamento in GKE non è ancora stato risolto. La richiesta di merge è ancora un Work in Progress (WIP), il che significa che non è stata ancora apportata nessuna modifica. Sulla RM è presente un commento di Terraform, dal quale si evince che il computo dei nodi deve passare da 2 a 5 per predisporre l'ambiente GKE all'esecuzione del deployment. Il responsabile dell'approvazione della RM fa clic sul'opzione di risoluzione dello stato di WIP per avviare la pipeline, e può scegliere di eliminare il ramo di origine in modo da eseguire il merge del nuovo computo dei nodi.
Affinché GitLab possa rivelarsi uno strumento di collaborazione efficace, è necessario garantirne la trasparenza per tutti i membri dell'organizzazione, in modo che possano visualizzare un ticket e la RM correlata per impostazione predefinita. Il ticket e la RM possono essere assegnati a un collaboratore, oppure quest'ultimo può essere taggato nella sezione dei commenti in modo da aggiungere l'attività alla sua lista di cose da fare.
Tornando alla vista dell'epic, ovvero la schermata che verrà utilizzata più spesso dagli stakeholder per monitorare l'avanzamento del progetto, i team possono riscontrare che il deployment per il ridimensionamento di GKE a cinque nodi è in corso.
Utilizzando GitLab per un flusso di lavoro GitOps, ogni membro del team è in grado di lavorare dallo stesso sistema e comprendere lo stato dei progetti. Che si tratti dell'infrastruttura o di sviluppo applicativo, tutte le modifiche seguono lo stesso processo di definizione delle attività, assegnazione ai singoli dipendenti, collaborazione con i colleghi, deployment di quel codice e utilizzo del repository Git come unica fonte di riferimento.
Vuoi iniziare?
Scopri cosa è capace di fare il tuo team grazie a una piattaforma DevSecOps unificata.