En GitLab, procesamos as correccións de software de dúas formas: manual e automaticamente. Continúa lendo para coñecer o traballo do xestor de versións de crear e entregar actualizacións importantes mediante a implementación automatizada en gitlab.com, así como os parches cos que os usuarios poden traballar nas súas propias instalacións.
Recomendo configurar un recordatorio no teu reloxo intelixente: o día 22 de cada mes, os usuarios que traballan con GitLab nas súas instalacións poden ver actualizacións da versión actual do noso produto. A versión mensual contén novas funcións, desenvolvementos das existentes e moitas veces mostra o resultado final das solicitudes da comunidade de ferramentas ou fusións.
Pero, como mostra a práctica, o desenvolvemento de software raramente está exento de fallos. Cando se descobre un erro ou unha vulnerabilidade de seguranza, o xestor de versións do equipo de entrega crea un parche para os nosos usuarios coas súas instalacións. Gitlab.com actualízase durante o proceso do CD. Chamamos a este proceso de CD despregamento automático para evitar confusións coa función de CD en GitLab. Este proceso pode incorporar suxestións de solicitudes de extracción enviadas por usuarios, clientes e o noso equipo de desenvolvemento interno, de xeito que resolver o aburrido problema de liberar parches resólvese de dúas formas moi diferentes.
«Asegurámonos de que todo o que fan os desenvolvedores se despregue en todos os ambientes todos os días antes de lanzalo a GitLab.com", explica , Responsable Técnico Superior, Departamento de Infraestruturas. "Pensa nos lanzamentos das túas instalacións como instantáneas para as implementacións de gitlab.com, para as que engadimos pasos separados para crear un paquete para que os nosos usuarios poidan usalo para instalalo nas súas instalacións.».
Independentemente do erro ou vulnerabilidade, os clientes de gitlab.com recibirán correccións pouco despois de publicarse, o que é un beneficio do proceso automatizado do CD. Os parches para usuarios con instalacións propias requiren unha preparación separada por parte do xestor de versións.
O equipo de entrega está a traballar duro para automatizar a maioría dos procesos implicados na creación de versións para reducir (tempo medio ata a produción, é dicir, o tempo dedicado á produción), o período de tempo desde o procesamento dunha solicitude de combinación por parte dun programador ata a implantación en gitlab.com.
«O obxectivo do equipo de entrega é asegurarnos de que podemos movernos máis rápido como empresa, ou polo menos facer que os repartidores traballen máis rápido, non é certo.?, di Marín.
Tanto os clientes de gitlab.com como os usuarios das súas instalacións benefícianse dos esforzos do equipo de entrega para reducir os tempos de ciclo e acelerar as implantacións. Neste artigo explicaremos as semellanzas e diferenzas entre estes dous métodos. , e tamén describiremos como o noso equipo de entrega prepara parches para os usuarios que traballan nas súas instalacións, así como como nos aseguramos de que gitlab.com estea actualizado mediante a implementación automatizada.
Que fai un xestor de versións?
Membros do equipo mensualmente as nosas versións para os usuarios nas súas instalacións, incluídos os parches e as versións de seguranza que se poidan producir entre as versións. Tamén son os responsables de liderar a transición da empresa cara á implantación automatizada e continua.
As versións de autoinstalación e as de gitlab.com usan fluxos de traballo similares pero execútanse en momentos diferentes, explica Marín.
En primeiro lugar, o xestor de versións, independentemente do tipo de lanzamento, garante que GitLab estea dispoñible e seguro desde o momento en que se lanza a aplicación en gitlab.com, incluíndo asegurarse de que os mesmos problemas non acaben na infraestrutura dos clientes cos seus capacidades propias.
Unha vez que un erro ou unha vulnerabilidade se marca como arranxado en GitLab, o xestor de versións debe avaliar que se incluirá nos parches ou actualizacións de seguranza dos usuarios coas súas instalacións. Se decide que un erro ou unha vulnerabilidade merece unha actualización, comeza o traballo preparatorio.
O xestor de versións debe decidir se prepara unha corrección ou cando a implementa, e isto depende moito do contexto da situación ".mentres tanto, as máquinas non son tan boas para xestionar o contexto como as persoas", di Marín.
Todo é sobre as correccións
Que son os parches e por que os necesitamos?
O xestor de versións decide se liberar unha corrección en función da gravidade do erro.
Os erros varían segundo a súa gravidade. Polo tanto, os erros S4 ou S3 poden ser estilísticos, como o desprazamento de píxeles ou iconas. Isto non é menos importante, pero non hai un impacto significativo no fluxo de traballo de ninguén, o que significa que a probabilidade de que se cree unha corrección para eses erros S3 ou S4 é pequena, explica Marín.
Non obstante, as vulnerabilidades S1 ou S2 significan que o usuario non debe actualizarse á versión máis recente ou que hai un erro significativo que afecta o fluxo de traballo do usuario. Se están incluídos no rastreador, moitos usuarios atopáronse con eles, polo que o xestor de versións comeza inmediatamente a preparar unha corrección.
Unha vez que está listo un parche para as vulnerabilidades S1 ou S2, o xestor de versións comeza a lanzar o parche.
Por exemplo, o parche de GitLab 12.10.1 creouse despois de que se identificaron varios problemas de bloqueo e que os desenvolvedores solucionaran o problema subxacente que os estaba causando. O xestor de lanzamentos avaliou a corrección dos niveis de gravidade asignados e, tras a confirmación, iniciouse o proceso de liberación dunha corrección, que estaba lista nas XNUMX horas despois de que se descubrisen os problemas de bloqueo.
Cando se acumulan moitos S4, S3 e S2, o xestor de versións analiza o contexto para determinar a urxencia de lanzar unha corrección e, cando se alcanza un determinado número deles, combínanse e lánzanse todos. As correccións posteriores ao lanzamento ou as actualizacións de seguranza resúmense nas publicacións do blog.
Como un xestor de versións crea parches
Usamos GitLab CI e outras funcións como os nosos ChatOps para xerar parches. O xestor de versións inicia o lanzamento da corrección activando o equipo de ChatOps na nosa canle interna #releases en Slack.
/chatops run release prepare 12.10.1ChatOps funciona dentro de Slack para desencadear diferentes eventos, que despois son procesados e executados por GitLab. Por exemplo, o equipo de entrega configurou ChatOps para automatizar varias cousas para lanzar parches.
Unha vez que o xestor de versións inicia o equipo de ChatOps en Slack, o resto do traballo ocorre automaticamente en GitLab mediante CICD. Hai unha comunicación bidireccional entre ChatOps en Slack e GitLab durante o proceso de lanzamento xa que o xestor de lanzamentos activa algúns dos pasos principais do proceso.
O seguinte vídeo mostra o proceso técnico de preparación dun parche para GitLab.
Como funciona a implementación automática en gitlab.com
O proceso e as ferramentas empregadas para actualizar gitlab.com son similares aos utilizados para crear parches. A actualización de gitlab.com require menos traballo manual desde o punto de vista do xestor de versións.
En lugar de executar implementacións usando ChatOps, usamos funcións de CI, por exemplo. , co que o xestor de versións pode programar determinadas accións para que se realicen no momento necesario. En lugar dun proceso manual, hai unha canalización que se executa periodicamente unha vez por hora que descarga os novos cambios realizados nos proxectos de GitLab, empaquetaos e programa a implantación e executa automaticamente probas, control de calidade e outros pasos necesarios.
"Entón, temos moitas implementacións en diferentes ambientes antes de gitlab.com, e despois de que eses ambientes estean en boa forma e as probas mostran bos resultados, o xestor de versións inicia as accións de implementación de gitlab.com", di Marín.
A tecnoloxía CICD para soportar as actualizacións de gitlab.com automatiza todo o proceso ata o punto en que o xestor de versións debe iniciar manualmente a implantación do ambiente de produción en gitlab.com.
Marín entra en detalles sobre o proceso de actualización de gitlab.com no seguinte vídeo.
Que máis fai o equipo de entrega?
A principal diferenza entre os procesos de actualización de gitlab.com e o lanzamento de parches aos clientes internos é que este último proceso require máis tempo e máis traballo manual do xestor de versións.
"Ás veces atrasamos o lanzamento de parches aos clientes coas súas instalacións debido a problemas informados, problemas de ferramentas e porque hai moitos matices que hai que ter en conta ao lanzar un único parche", di Marín.
Un dos obxectivos a curto prazo do equipo de entrega é reducir a cantidade de traballo manual por parte do xestor de lanzamento para acelerar o lanzamento. O equipo está a traballar para simplificar, racionalizar e automatizar o proceso de lanzamento, o que axudará a solucionar problemas de baixa gravidade (S3 e S4, aprox. tradutor). Centrarse na velocidade é un indicador clave de rendemento: é necesario reducir o MTTP -o tempo desde a recepción dunha solicitude de combinación ata a implantación do resultado en gitlab.com- das 50 horas actuais a 8 horas.
O equipo de entrega tamén está a traballar na migración de gitlab.com a unha infraestrutura baseada en Kubernetes.
Editor n.b.: Se xa escoitaches falar da tecnoloxía de Kubernetes (e non dubido que si), pero aínda non a tocaches coas túas mans, recoméndoche participar en cursos intensivos en liña. , que se celebrará do 28 ao 30 de setembro, e , que terá lugar do 14 ao 16 de outubro. Isto permitirache navegar e traballar con confianza coa tecnoloxía.
Estes son dous enfoques que perseguen o mesmo obxectivo: entrega rápida de actualizacións, tanto para gitlab.com como para os clientes das súas instalacións.
Algunha idea ou recomendación para nós?
Todos poden contribuír a GitLab e agradecemos os comentarios dos nosos lectores. Se tes algunha idea para o noso equipo de entrega, non o dubides con aviso team: Delivery.
Fonte: www.habr.com