A GitLab, processem les correccions de programari de dues maneres: manualment i automàticament. Continueu llegint per conèixer la feina del gestor de llançaments de crear i lliurar actualitzacions importants mitjançant el desplegament automatitzat a gitlab.com, així com els pedaços perquè els usuaris puguin treballar a les seves pròpies instal·lacions.
Us recomano establir un recordatori al vostre rellotge intel·ligent: cada mes, el dia 22, els usuaris que treballen amb GitLab a les seves instal·lacions poden veure actualitzacions de la versió actual del nostre producte. El llançament mensual conté funcions noves, desenvolupaments de les existents i sovint mostra el resultat final de les sol·licituds de la comunitat d'eines o fusions.
Però, com mostra la pràctica, el desenvolupament de programari rarament no té defectes. Quan es descobreix un error o una vulnerabilitat de seguretat, el gestor de llançaments de l'equip de lliurament crea un pedaç per als nostres usuaris amb les seves instal·lacions. Gitlab.com s'actualitza durant el procés del CD. Anomenem aquest procés de CD desplegament automàtic per evitar confusions amb la funció de CD a GitLab. Aquest procés pot incorporar suggeriments de les sol·licituds d'extracció enviades pels usuaris, els clients i el nostre equip de desenvolupament intern, de manera que resoldre l'avorrit problema de llançar pegats es resol de dues maneres molt diferents.
«Ens assegurem que tot el que fan els desenvolupadors es desplega a tots els entorns cada dia abans de llançar-lo a GitLab.com", explica , Responsable Tècnic Superior, Departament d'Infraestructures. "Penseu en les versions de les vostres instal·lacions com a instantànies per a desplegaments de gitlab.com, per als quals hem afegit passos separats per crear un paquet perquè els nostres usuaris puguin utilitzar-lo per instal·lar-los a les seves instal·lacions.».
Independentment de l'error o la vulnerabilitat, els clients de gitlab.com rebran correccions poc després de la seva publicació, cosa que és un avantatge del procés de CD automatitzat. Els pedaços per als usuaris amb instal·lacions pròpies requereixen una preparació independent per part del gestor de versions.
L'equip de lliurament està treballant dur per automatitzar la majoria dels processos implicats en la creació de versions per reduir (temps mitjà fins a la producció, és a dir, temps dedicat a la producció), el període de temps des del processament d'una sol·licitud de combinació per part d'un desenvolupador fins al desplegament a gitlab.com.
«L'objectiu de l'equip de lliurament és assegurar-nos que podem moure'ns més ràpidament com a empresa, o almenys fer que els repartidors treballin més ràpid, oi.?, diu Marín.
Tant els clients de gitlab.com com els usuaris de les seves instal·lacions es beneficien dels esforços de l'equip de lliurament per reduir els temps de cicle i accelerar els desplegaments. En aquest article explicarem les semblances i diferències entre aquests dos mètodes. , i també descriurem com el nostre equip de lliurament prepara els pedaços per als usuaris que treballen a les seves instal·lacions, així com com ens assegurem que gitlab.com estigui actualitzat mitjançant el desplegament automatitzat.
Què fa un gestor de llançaments?
Membres de l'equip mensualment les nostres versions als usuaris a les seves instal·lacions, inclosos els pedaços i les versions de seguretat que es poden produir entre versions. També són els responsables de liderar la transició de l'empresa cap a un desplegament automatitzat i continu.
Les versions d'autoinstal·lació i les versions de gitlab.com utilitzen fluxos de treball similars, però s'executen en moments diferents, explica Marin.
En primer lloc, el gestor de llançaments, independentment del tipus de llançament, assegura que GitLab estigui disponible i segur des del moment en què es llança l'aplicació a gitlab.com, inclòs assegurant que els mateixos problemes no acabin a la infraestructura dels clients amb els seus capacitats pròpies.
Un cop s'ha marcat un error o una vulnerabilitat com a corregit a GitLab, el gestor de versions ha d'avaluar que s'inclourà als pedaços o actualitzacions de seguretat dels usuaris amb les seves instal·lacions. Si decideix que un error o una vulnerabilitat mereix una actualització, comença el treball preparatori.
El gestor de llançaments ha de decidir si prepara una solució o quan la implementa, i això depèn molt del context de la situació".mentrestant, les màquines no són tan bones per gestionar el context com les persones", diu Marín.
Tot es tracta de les correccions
Què són els pegats i per què els necessitem?
El gestor de llançaments decideix si llança una correcció en funció de la gravetat de l'error.
Els errors varien en funció de la seva gravetat. Així, els errors S4 o S3 poden ser estilístics, com ara el desplaçament de píxels o icones. Això no és menys important, però no hi ha cap impacte significatiu en el flux de treball de ningú, la qual cosa significa que la probabilitat que es creï una solució per a aquests errors S3 o S4 és petita, explica Marin.
Tanmateix, les vulnerabilitats S1 o S2 fan que l'usuari no s'actualitzi a l'última versió o hi hagi un error important que afecta el flux de treball de l'usuari. Si s'inclouen al rastrejador, molts usuaris els han trobat, de manera que el gestor de llançaments comença immediatament a preparar una solució.
Un cop està preparat un pedaç per a les vulnerabilitats S1 o S2, el gestor de llançaments comença a llançar-lo.
Per exemple, el pedaç de GitLab 12.10.1 es va crear després que s'identifiquessin diversos problemes de bloqueig i els desenvolupadors solucionessin el problema subjacent que els causava. El gestor de llançaments va avaluar la correcció dels nivells de gravetat assignats i, després de la confirmació, es va iniciar el procés d'alliberament d'una correcció, que estava a punt en les XNUMX hores posteriors a la descoberta dels problemes de bloqueig.
Quan s'acumulen molts S4, S3 i S2, el gestor de llançaments mira el context per determinar la urgència d'alliberar una correcció i, quan s'arriba a un nombre determinat, es combinen i es publiquen. Les correccions posteriors al llançament o les actualitzacions de seguretat es resumeixen a les publicacions del bloc.
Com un gestor de versions crea pedaços
Utilitzem GitLab CI i altres funcions com els nostres ChatOps per generar pedaços. El gestor de llançaments inicia el llançament de la correcció activant l'equip de ChatOps al nostre canal intern #releases en Slack.
/chatops run release prepare 12.10.1ChatOps funciona dins de Slack per desencadenar diferents esdeveniments, que després són processats i executats per GitLab. Per exemple, l'equip de lliurament va configurar ChatOps per automatitzar diverses coses per llançar pedaços.
Una vegada que el gestor de llançaments inicia l'equip de ChatOps a Slack, la resta del treball passa automàticament a GitLab mitjançant CICD. Hi ha una comunicació bidireccional entre ChatOps a Slack i GitLab durant el procés de llançament, ja que el gestor de llançaments activa alguns dels passos principals del procés.
El vídeo següent mostra el procés tècnic de preparar un pedaç per a GitLab.
Com funciona el desplegament automàtic a gitlab.com
El procés i les eines que s'utilitzen per actualitzar gitlab.com són similars als que s'utilitzen per crear pedaços. L'actualització de gitlab.com requereix menys treball manual des del punt de vista del gestor de llançaments.
En lloc d'executar desplegaments mitjançant ChatOps, utilitzem funcions de CI, p. ex. , amb la qual el gestor de versions pot programar determinades accions per dur a terme en el moment requerit. En lloc d'un procés manual, hi ha una canalització que s'executa periòdicament una vegada per hora que descarrega els nous canvis fets als projectes de GitLab, els empaqueta i programa el desplegament i executa automàticament proves, control de qualitat i altres passos necessaris.
"Per tant, tenim molts desplegaments en entorns diferents abans de gitlab.com, i després que aquests entorns estiguin en bon estat i les proves mostrin bons resultats, el gestor de llançaments inicia les accions de desplegament de gitlab.com", diu Marin.
La tecnologia CICD per donar suport a les actualitzacions de gitlab.com automatitza tot el procés fins al punt que el gestor de versions ha de llançar manualment el desplegament de l'entorn de producció a gitlab.com.
Marin entra en detalls sobre el procés d'actualització de gitlab.com al vídeo següent.
Què més fa l'equip de lliurament?
La diferència principal entre els processos d'actualització de gitlab.com i el llançament de pedaços als clients interns és que aquest darrer procés requereix més temps i més treball manual per part del gestor de llançaments.
"De vegades retardem l'alliberament de pedaços als clients amb les seves instal·lacions a causa de problemes reportats, problemes d'eines i perquè hi ha molts matisos que cal tenir en compte a l'hora de llançar un únic pegat", diu Marin.
Un dels objectius a curt termini de l'equip de lliurament és reduir la quantitat de treball manual per part del gestor de llançaments per accelerar el llançament. L'equip està treballant per simplificar, racionalitzar i automatitzar el procés de llançament, cosa que ajudarà a solucionar problemes de baixa gravetat (S3 i S4, aprox. traductor). Centrar-se en la velocitat és un indicador clau de rendiment: cal reduir el MTTP (el temps des de rebre una sol·licitud de combinació fins a desplegar el resultat a gitlab.com) de les 50 hores actuals a 8 hores.
L'equip de lliurament també està treballant en la migració de gitlab.com a una infraestructura basada en Kubernetes.
Editor n.b.: Si ja heu sentit a parlar de la tecnologia Kubernetes (i no dubto que sí), però encara no l'heu tocat amb les mans, us recomano participar en cursos intensius en línia. , que se celebrarà del 28 al 30 de setembre, i , que tindrà lloc del 14 al 16 d'octubre. Això us permetrà navegar amb confiança i treballar amb la tecnologia.
Es tracta de dos enfocaments que persegueixen el mateix objectiu: lliurament ràpid d'actualitzacions, tant per a gitlab.com com per als clients de les seves instal·lacions.
Alguna idea o recomanació per a nosaltres?
Tothom és benvingut a contribuir a GitLab i agraïm els comentaris dels nostres lectors. Si teniu alguna idea per al nostre equip de lliurament, no ho dubteu amb avís team: Delivery.
Font: www.habr.com