In GitLab, elaboriamo le correzioni del software in due modi: manualmente e automaticamente. Continua a leggere per conoscere il lavoro del gestore del rilascio di creare e fornire aggiornamenti importanti tramite distribuzione automatizzata su gitlab.com, nonché patch con cui gli utenti possono lavorare sulle proprie installazioni.
Ti consiglio di impostare un promemoria sul tuo smartwatch: il 22 di ogni mese, gli utenti che lavorano con GitLab presso le loro strutture potranno vedere gli aggiornamenti alla versione attuale del nostro prodotto. La versione mensile contiene nuove funzionalità, sviluppi di quelle esistenti e spesso mostra il risultato finale delle richieste della comunità per strumenti o fusioni.
Ma, come dimostra la pratica, lo sviluppo del software raramente è privo di difetti. Quando viene scoperto un bug o una vulnerabilità della sicurezza, il responsabile del rilascio del team di consegna crea una patch per i nostri utenti con le loro installazioni. Gitlab.com viene aggiornato durante il processo del CD. Chiamiamo questo processo CD distribuzione automatica per evitare confusione con la funzionalità CD in GitLab. Questo processo può incorporare suggerimenti provenienti da richieste pull inviate da utenti, clienti e dal nostro team di sviluppo interno, in modo che il noioso problema del rilascio delle patch venga risolto in due modi molto diversi.
«Ci assicuriamo che tutto ciò che gli sviluppatori realizzano venga distribuito in tutti gli ambienti ogni giorno prima di distribuirlo su GitLab.com", spiega , Direttore Tecnico Senior, Dipartimento Infrastrutture. "Pensa alle versioni per le tue installazioni come istantanee per le distribuzioni di gitlab.com, per le quali abbiamo aggiunto passaggi separati per creare un pacchetto in modo che i nostri utenti possano utilizzarlo per installarlo sulle loro installazioni'.
Indipendentemente dal bug o dalla vulnerabilità, i clienti di gitlab.com riceveranno le correzioni poco dopo la loro pubblicazione, il che è un vantaggio del processo CD automatizzato. Le patch per gli utenti con le proprie installazioni richiedono una preparazione separata da parte del gestore del rilascio.
Il team di consegna sta lavorando duramente per automatizzare la maggior parte dei processi coinvolti nella creazione di versioni da ridurre (tempo medio di produzione, ovvero il tempo impiegato nella produzione), il periodo di tempo dall'elaborazione di una richiesta di unione da parte di uno sviluppatore alla distribuzione su gitlab.com.
«L'obiettivo del team di consegna è quello di garantire che possiamo muoverci più velocemente come azienda, o almeno far sì che gli addetti alle consegne lavorino più velocemente, giusto?, dice Marin.
Sia i clienti di gitlab.com che gli utenti delle loro installazioni beneficiano degli sforzi del team di consegna per ridurre i tempi di ciclo e accelerare le implementazioni. In questo articolo spiegheremo le somiglianze e le differenze tra questi due metodi. e descriveremo anche il modo in cui il nostro team di distribuzione prepara le patch per gli utenti che lavorano nelle loro strutture, nonché il modo in cui garantiamo che gitlab.com sia aggiornato utilizzando la distribuzione automatizzata.
Cosa fa un release manager?
Membri del team mensilmente i nostri rilasci agli utenti presso le loro strutture, comprese le patch e i rilasci di sicurezza che potrebbero verificarsi tra un rilascio e l'altro. Sono inoltre responsabili della guida della transizione dell'azienda verso un'implementazione automatizzata e continua.
Le versioni di autoinstallazione e le versioni di gitlab.com utilizzano flussi di lavoro simili ma vengono eseguite in momenti diversi, spiega Marin.
Innanzitutto il release manager, indipendentemente dal tipo di release, garantisce che GitLab sia disponibile e sicuro dal momento in cui l'applicazione viene lanciata su gitlab.com, garantendo anche che le stesse problematiche non finiscano nell'infrastruttura dei clienti con i loro proprie capacità.
Una volta che un bug o una vulnerabilità vengono contrassegnati come risolti in GitLab, il release manager deve valutare se verrà incluso nelle patch o negli aggiornamenti di sicurezza per gli utenti con le loro installazioni. Se decide che un bug o una vulnerabilità meritano un aggiornamento, inizia il lavoro preparatorio.
Il release manager deve decidere se preparare una correzione o quando implementarla, e questo dipende fortemente dal contesto della situazione, "nel frattempo, le macchine non sono altrettanto brave a gestire il contesto quanto le persone" dice Marino.
È tutta una questione di soluzioni
Cosa sono le patch e perché ne abbiamo bisogno?
Il gestore del rilascio decide se rilasciare una correzione in base alla gravità del bug.
Gli errori variano a seconda della loro gravità. Quindi gli errori S4 o S3 possono essere stilistici, come lo spostamento di pixel o icone. Questo non è meno importante, ma non ha alcun impatto significativo sul flusso di lavoro di nessuno, il che significa che la probabilità che venga creata una correzione per tali errori S3 o S4 è piccola, spiega Marin.
Tuttavia, le vulnerabilità S1 o S2 indicano che l'utente non deve eseguire l'aggiornamento alla versione più recente oppure è presente un bug significativo che influisce sul flusso di lavoro dell'utente. Se sono inclusi nel tracker, molti utenti li hanno riscontrati, quindi il gestore del rilascio inizia immediatamente a preparare una correzione.
Una volta pronta una patch per le vulnerabilità S1 o S2, il gestore del rilascio inizia a rilasciare la patch.
Ad esempio, la patch GitLab 12.10.1 è stata creata dopo che sono stati identificati diversi problemi di blocco e gli sviluppatori hanno risolto il problema sottostante che li causava. Il Release manager ha valutato la correttezza dei livelli di gravità assegnati e, dopo la conferma, è stato avviato il processo di rilascio di un fix, che era pronto entro XNUMX ore dalla scoperta dei problemi bloccanti.
Quando si accumulano molti S4, S3 e S2, il gestore dei rilasci esamina il contesto per determinare l'urgenza di rilasciare una correzione e, quando viene raggiunto un certo numero, vengono tutti combinati e rilasciati. Le correzioni successive al rilascio o gli aggiornamenti di sicurezza sono riepilogati nei post del blog.
Come un release manager crea le patch
Utilizziamo GitLab CI e altre funzionalità come le nostre ChatOps per generare patch. Il Release Manager attiva il rilascio della correzione attivando il team ChatOps sul nostro canale interno #releases in Slack.
/chatops run release prepare 12.10.1ChatOps funziona all'interno di Slack per attivare diversi eventi, che vengono poi elaborati ed eseguiti da GitLab. Ad esempio, il team di consegna ha configurato ChatOps per automatizzare varie operazioni relative al rilascio delle patch.
Una volta che il gestore del rilascio avvia il team ChatOps in Slack, il resto del lavoro avviene automaticamente in GitLab utilizzando CICD. Esiste una comunicazione bidirezionale tra ChatOps in Slack e GitLab durante il processo di rilascio poiché il gestore del rilascio attiva alcuni dei passaggi principali del processo.
Il video qui sotto mostra il processo tecnico di preparazione di una patch per GitLab.
Come funziona la distribuzione automatica su gitlab.com
Il processo e gli strumenti utilizzati per aggiornare gitlab.com sono simili a quelli utilizzati per creare patch. L'aggiornamento di gitlab.com richiede meno lavoro manuale dal punto di vista del gestore del rilascio.
Invece di eseguire distribuzioni utilizzando ChatOps, utilizziamo funzionalità CI, ad es. , con il quale il release manager può programmare determinate azioni da eseguire al momento richiesto. Invece di un processo manuale, esiste una pipeline che viene eseguita periodicamente una volta all'ora che scarica le nuove modifiche apportate ai progetti GitLab, le raggruppa e pianifica la distribuzione ed esegue automaticamente test, QA e altri passaggi necessari.
"Quindi abbiamo molte distribuzioni in esecuzione in ambienti diversi prima di gitlab.com e, dopo che tali ambienti sono in buone condizioni e i test mostrano buoni risultati, il gestore del rilascio avvia le azioni di distribuzione di gitlab.com", afferma Marin.
La tecnologia CICD per supportare gli aggiornamenti di gitlab.com automatizza l'intero processo al punto in cui il gestore del rilascio deve avviare manualmente la distribuzione dell'ambiente di produzione su gitlab.com.
Marin entra nei dettagli sul processo di aggiornamento di gitlab.com nel video qui sotto.
Cos'altro fa il team di consegna?
La differenza principale tra i processi di aggiornamento di gitlab.com e il rilascio interno delle patch ai clienti è che quest'ultimo processo richiede più tempo e più lavoro manuale da parte del gestore del rilascio.
"A volte ritardiamo il rilascio delle patch ai clienti con le loro installazioni a causa di problemi segnalati, problemi con gli strumenti e perché ci sono molte sfumature che devono essere prese in considerazione quando si rilascia una singola patch", afferma Marin.
Uno degli obiettivi a breve termine del team di consegna è ridurre la quantità di lavoro manuale da parte del responsabile del rilascio per accelerare il rilascio. Il team sta lavorando per semplificare, ottimizzare e automatizzare il processo di rilascio, che aiuterà a ottenere soluzioni a problemi di bassa gravità (S3 e S4, ca. traduttore). Concentrarsi sulla velocità è un indicatore chiave di prestazione: è necessario ridurre l'MTTP - il tempo che intercorre tra la ricezione di una richiesta di unione e la distribuzione del risultato su gitlab.com - dalle attuali 50 ore a 8 ore.
Il team di consegna sta anche lavorando alla migrazione di gitlab.com su un'infrastruttura basata su Kubernetes.
N.B. dell'editore: Se hai già sentito parlare della tecnologia Kubernetes (e non ho dubbi che tu ne abbia), ma non l'hai ancora toccata con mano, ti consiglio di partecipare ai corsi intensivi online , che si terrà dal 28 al 30 settembre, e , che si svolgerà dal 14 al 16 ottobre. Ciò ti consentirà di navigare e lavorare con sicurezza con la tecnologia.
Si tratta di due approcci che perseguono lo stesso obiettivo: consegna rapida degli aggiornamenti, sia per gitlab.com che per i clienti presso le loro strutture.
Qualche idea o consiglio per noi?
Tutti sono invitati a contribuire a GitLab e accogliamo con favore il feedback dei nostri lettori. Se hai qualche idea per il nostro team di consegna, non esitare segnato team: Delivery.
Fonte: habr.com