Segui la tua strada con GitLab
Condividi sui social
Segui la tua strada con GitLab
Val Naipaul
23rd gennaio, 2024
11 min di lettura
Val Naipaul
23rd gennaio, 2024
11 min di lettura
Vai alla sezione
Vai alla sezione
Approcci comuni
Approccio proposto
E che dire di Auto DevOps?
Se lavori sul lato piattaforma e/o DevOps e devi affrontare una migrazione o implementazione di GitLab (SaaS o autogestito), potresti scoprire che GitLab ha molti pulsanti e interruttori.
È infatti una piattaforma completa, capace di coprire l’ampiezza e la profondità delle tue esigenze, con il suo VCS centrale, le pipeline CI/CD, la gestione dei pacchetti, l’analisi della composizione del software, le funzionalità di pianificazione e altro ancora.
Ma devi implementare tutte le funzionalità per riuscire nel tuo intento? In particolare se si tratta di GitLab Runners, implementato sul cloud, che influisce sui profitti.
In questo blog, ti proponiamo un approccio alla pianificazione di una migrazione o implementazione di GitLab capace di offrire rapidamente valore agli stakeholder e aiutare i team a interagire con GitLab alle loro condizioni, senza necessariamente andare a tutta velocità.
Approcci comuni
Prima di analizzare l’approccio che proponiamo per una migrazione o implementazione di GitLab, parleremo di alcuni approcci comuni in base al contesto che potrebbero forse rivelarsi più adatti alla tua situazione.
Big bang (migrazione)
L’approccio big bang prevede iterazioni di analisi, configurazione, ETL e convalida, possibilmente utilizzando inizialmente contenuti di origine rappresentativi per poi arrivare fino all’intero contenuto di origine e culminando in una migrazione finale stile “big bang”.
Il vantaggio principale è un chiaro punto di cutover per tutti i soggetti coinvolti, anche se i valori differiranno fino a quel momento. La natura iterativa di questo approccio può anche creare inefficienze strutturali, sotto forma di spese generali collegate alle iterazioni di migrazione.
Incrementale, graduale (migrazione)
In un approccio incrementale, il contenuto di origine viene partizionato e migrato in incrementi. Ciò può anche avvenire in modo iterativo, come con l’approccio “big bang”, ma con iterazioni più gestibili.
In un approccio graduale, le funzionalità dell’ambiente di destinazione vengono attivate in fasi dove ognuna è basata su quelle precedenti.
In entrambi questi approcci, il valore viene realizzato più rapidamente rispetto al metodo “big bang”, ma sia le piattaforme di origine che quelle di destinazione sono attive per un periodo prolungato, dal primo incremento o fase fino all’ultimo, in un processo che può diventare gravoso e confuso.
Platform engineering con self-service (migrazione/implementazione)
Nel platform engineering con approccio self-service, un team di esperti getta le basi (configurazione, automazione, protezione) per consentire ai team di sviluppo di utilizzare GitLab, indipendentemente dal fatto che ciò comporti la migrazione di contenuti, l’onboard o il bootstrap di nuovi progetti utilizzando modelli consentiti e approvati.
Sebbene questo approccio possa funzionare senza un framework per un’esperienza di sviluppo standardizzata, ovvero una piattaforma di sviluppo interna (IDP) e semplicemente basandosi su conoscenze condivise e disciplina di squadra, risulta estremamente migliore se, invece, dispone di un framework di appoggio. Le opzioni IDP includono Backstage, Compass, Venue.she GitLab stesso.
Approccio proposto
Un approccio “shift left” con priorità di valore alla migrazione o all’implementazione di GitLab
L’approccio che proponiamo dà priorità alla fornitura di valore agli stakeholder e al contempo stimola l’implementazione per garantire un solido coinvolgimento tra utenti e GitLab.
Ad esempio, se i tuoi team vogliono utilizzare GitLab Review Apps ai fini della collaborazione (e per ridurre, forse, i profitti dell’infrastruttura), potresti prendere in considerazione le integrazioni di repository esterni come bypass per Review Apps prima che i repository Git siano stati completamente migrati o prima dell’inizio della migrazione.
Sebbene accelerare il roll-out potrebbe avere senso per alcuni aspetti, potrebbe invece essere utile rallentarne altri, come il mirroring automatico dei problemi da uno strumento di pianificazione esistente a GitLab Team Planning. Ciò consentirà agli sviluppatori di effettuare la transizione seguendo il proprio ritmo, con interruzioni minime.
Per inciso, sebbene non sia normalmente utilizzato nel contesto dell’implementazione/migrazione della piattaforma, il pensiero “shift left” è al centro di questo approccio. Amplierai il piano per prendere in considerazione le diverse parti interessate e le loro preoccupazioni (ad esempio, costi ed esperienza degli sviluppatori) insieme ai normali problemi di implementazione/migrazione della piattaforma.
Principi generali
Questo approccio prevede prima di tutto l’identificazione dei criteri di successo con GitLab, quindi l’assegnazione della giusta priorità a ciascuno sulla base di tre attributi:
- Importanza/urgenza o “dimensione”
- Costo di implementazione
- Trazione (il capitale umano, le competenze e l’impegno necessari)
Procedere con la migrazione o l’implementazione in base alle priorità stabilite fornirà valore più rapidamente agli stakeholder, promuovendo, al contempo, l’impegno dei team con GitLab.
Identifica i tuoi criteri per il successo.
In base a quali criteri verrà misurato il successo (da tutte le parti interessate, non solo dal tuo team)? Identifica almeno due criteri, ma non più di cinque.
I tuoi criteri, come le ben note metriche DORA, potrebbero essere associati a DevOps. Ricorda, si tratta del tuo ambiente: i problemi di sicurezza e conformità occupano una posizione di rilievo? C’è un interesse significativo per il rigore e la trasparenza dei test?
Dai priorità ai tuoi criteri per il successo e abbinali alle funzionalità di GitLab
Per ogni criterio di successo:
- Assegna un numero per rappresentare la dimensione relativa, utilizzando 1 per il minimo (i criteri più importanti/urgenti hanno la priorità più alta). Lascia spazi tra i criteri per rappresentare al meglio i valori relativi, ad esempio 1, 2, 3, 5, 10.
- Assegna un numero per rappresentare il costo di implementazione relativo (inclusi strumenti e processi) per passare dallo stato corrente allo stato target (rispetto al criterio), utilizzando 1 per il massimo (i criteri con costi di implementazione inferiori hanno la priorità più alta). Per lo stato target, pensa a breve e medio termine, ma non lasciare da parte l’ambizione: arrivarci deve sembrare un risultato.
- Assegna un numero per rappresentare la trazione relativa, utilizzando 1 per il minimo (i criteri con la trazione più alta meritano una priorità più alta). Chiedi se disponi del capitale umano, delle competenze e dell’impegno per realizzare guadagni.
- Ora classifica il criterio rispetto agli altri in base alla dimensione, al costo e alla trazione, con il risultato che le priorità più alte hanno una numerazione più alta.
- Identifica le funzionalità GitLab pertinenti che ti potrebbero aiutare (od ostacolare) e spiega come. Inizia con un criterio inclusivo e perfezionalo secondo necessità, possibilmente consultando gli stakeholder.
Ricevuto!
Ad esempio:
Criterio di successo - Collaborazione
- Dimensione - 5
- Costo - 4
- Trazione - 4
- Valore - 80
Funzionalità GitLab pertinenti
- InnerSourcing con una gerarchia di gruppo minima
- Sposta i contenuti sensibili fuori dai repository e procedi all’attivazione Secret Detection per supportare InnerSourcing (e migliorare la sicurezza)
- Tecniche di composizione della pipeline, come il riutilizzo tramite template, i componenti di CI/CDe il catalogo CI/CD
Criterio di successo - Costi operativi
- Dimensione - 1
- Costo - 3
- Trazione - 3
- Valore - 9
Funzionalità GitLab pertinenti
- Review Apps per ambienti di test effimeri
Criterio di successo - Costi operativi
- Dimensione - 3
- Costo - 1
- Trazione - 1
- Valore - 3
Funzionalità GitLab pertinenti
E che dire di Auto DevOps?
Che dire di Auto DevOps? Non include diversi modelli di branching, metodologie di sviluppo e cronologia - in altre parole, contenuti non uniformi? Non potremmo semplicemente saltare questa definizione delle priorità e fornire tutto contemporaneamente con Auto DevOps (mettendo da parte i costi operativi del cloud)?
No e no; Auto DevOps (che è solo un set di lavori di pipeline curati) è un buon modello e punto di partenza per DevSecOps e si presta alla personalizzazione e/o ispirazione per i tuoi componenti riutilizzabili di CI/CDe il catalogo CI/CD, ma non è un “modello di”, è solo un “modello per”.
Conclusioni
Ci auguriamo che questo post ti offra qualche strumento in più per procedere con una migrazione o implementazione di GitLab, sia SaaS che autogestita, con una prospettiva più ampia sulla pianificazione per ottenere un risultato di successo nel tuo ambiente.
Con l’approccio che abbiamo proposto, dando priorità ai tuoi criteri di successo in base a dimensione, costo dell’implementazionee trazione, i tuoi stakeholder vedranno il valore da GitLab più rapidamente. I tuoi utenti apprezzeranno il coinvolgimento significativo offerto da GitLab quando vedranno che i loro problemi vengono affrontati nell’implementazione.
Come abbiamo accennato in precedenza, GitLab ha molti pulsanti e interruttori. Per risultati ottimali con il nostro approccio proposto alla migrazione o all’implementazione di GitLab, esamina tutte le funzionalità offerte (prestando attenzione al piano di abbonamento applicabile, Premium o Ultimate). In questo modo, saprai quali funzionalità supportano al meglio i tuoi criteri di successo.
Contattaci per saperne di più!
Scritto da
Val Naipaul
Principal DevOps Consultant
Val applica il pensiero DevOps ai problemi del mondo reale, sviluppando la nostra pratica DevOps e condividendo idee ed esperienze con clienti e partner. Val lavora volentieri con storie e prospettive eterogenee per guidare l'innovazione.