En GitLab, procesamos correcciones de software de dos maneras: manual y automáticamente. Continúe leyendo para conocer el trabajo del administrador de versiones de crear y entregar actualizaciones importantes mediante implementación automatizada en gitlab.com, así como parches para que los usuarios trabajen con ellos en sus propias instalaciones.
Recomiendo configurar un recordatorio en tu reloj inteligente: cada mes, el día 22, los usuarios que trabajen con GitLab en sus instalaciones podrán ver las actualizaciones de la versión actual de nuestro producto. La versión mensual contiene nuevas funciones, desarrollos de las existentes y, a menudo, muestra el resultado final de las solicitudes de herramientas o fusiones de la comunidad.
Pero, como muestra la práctica, el desarrollo de software rara vez está libre de fallas. Cuando se descubre un error o una vulnerabilidad de seguridad, el administrador de versiones del equipo de entrega crea un parche para nuestros usuarios con sus instalaciones. Gitlab.com se actualiza durante el proceso del CD. A este proceso de CD lo llamamos implementación automática para evitar confusiones con la función de CD en GitLab. Este proceso puede incorporar sugerencias de solicitudes de extracción enviadas por usuarios, clientes y nuestro equipo de desarrollo interno, de modo que resolver el aburrido problema de lanzar parches se resuelve de dos maneras muy diferentes.
«Nos aseguramos de que todo lo que hacen los desarrolladores se implemente en todos los entornos todos los días antes de implementarlo en GitLab.com.", explica , Gerente Técnico Senior, Departamento de Infraestructura. "Piense en las versiones de sus instalaciones como instantáneas de las implementaciones de gitlab.com, para las cuales hemos agregado pasos separados para crear un paquete para que nuestros usuarios puedan usarlo para instalarlo en sus instalaciones.".
Independientemente del error o vulnerabilidad, los clientes de gitlab.com recibirán correcciones poco después de su publicación, lo cual es un beneficio del proceso de CD automatizado. Los parches para usuarios con sus propias instalaciones requieren una preparación separada por parte del administrador de versiones.
El equipo de entrega está trabajando arduamente para automatizar la mayoría de los procesos involucrados en la creación de versiones para reducir (tiempo medio de producción, es decir, tiempo dedicado a la producción), el período de tiempo desde que un desarrollador procesa una solicitud de fusión hasta la implementación en gitlab.com.
«El objetivo del equipo de entrega es asegurarse de que podamos avanzar más rápido como empresa, o al menos hacer que los repartidores trabajen más rápido, ¿verdad??, dice Marín.
Tanto los clientes de gitlab.com como los usuarios de sus instalaciones se benefician de los esfuerzos del equipo de entrega para reducir los tiempos de ciclo y acelerar las implementaciones. En este artículo explicaremos las similitudes y diferencias entre estos dos métodos. y también describiremos cómo nuestro equipo de entrega prepara parches para los usuarios que trabajan en sus instalaciones, así como también cómo nos aseguramos de que gitlab.com esté actualizado mediante la implementación automatizada.
¿Qué hace un administrador de versiones?
Miembros del equipo mensualmente nuestros lanzamientos a los usuarios en sus instalaciones, incluidos parches y lanzamientos de seguridad que pueden ocurrir entre lanzamientos. También son responsables de liderar la transición de la empresa hacia una implementación continua y automatizada.
Las versiones de autoinstalación y las versiones de gitlab.com utilizan flujos de trabajo similares pero se ejecutan en momentos diferentes, explica Marin.
En primer lugar, el administrador de versiones, independientemente del tipo de versión, garantiza que GitLab esté disponible y sea seguro desde el momento en que se inicia la aplicación en gitlab.com, lo que incluye garantizar que los mismos problemas no terminen en la infraestructura de los clientes con sus propias capacidades.
Una vez que un error o vulnerabilidad se marca como solucionado en GitLab, el administrador de lanzamientos debe evaluar que se incluirá en los parches o actualizaciones de seguridad para los usuarios con sus instalaciones. Si decide que un error o vulnerabilidad merece una actualización, comienza el trabajo preparatorio.
El administrador de versiones debe decidir si preparar una solución o cuándo implementarla, y esto depende en gran medida del contexto de la situación ".Mientras tanto, las máquinas no son tan buenas para gestionar el contexto como las personas." dice Marín.
Se trata de las correcciones
¿Qué son los parches y por qué los necesitamos?
El administrador de versiones decide si publicar una solución según la gravedad del error.
Los errores varían según su gravedad. Por lo tanto, los errores de S4 o S3 pueden ser estilísticos, como el desplazamiento de píxeles o iconos. Esto no es menos importante, pero no tiene un impacto significativo en el flujo de trabajo de nadie, lo que significa que la probabilidad de que se cree una solución para dichos errores S3 o S4 es pequeña, explica Marin.
Sin embargo, las vulnerabilidades S1 o S2 significan que el usuario no debe actualizar a la última versión o que hay un error importante que afecta el flujo de trabajo del usuario. Si están incluidos en el rastreador, muchos usuarios los han encontrado, por lo que el administrador de versiones comienza inmediatamente a preparar una solución.
Una vez que está listo un parche para las vulnerabilidades S1 o S2, el administrador de versiones comienza a publicar el parche.
Por ejemplo, el parche GitLab 12.10.1 se creó después de que se identificaron varios problemas de bloqueo y los desarrolladores solucionaron el problema subyacente que los estaba causando. El administrador de versiones evaluó la exactitud de los niveles de gravedad asignados y, después de la confirmación, se inició el proceso de publicación de una solución, que estuvo lista dentro de las XNUMX horas posteriores al descubrimiento de los problemas de bloqueo.
Cuando se acumulan muchos S4, S3 y S2, el administrador de versiones analiza el contexto para determinar la urgencia de publicar una solución y, cuando se alcanza un cierto número de ellas, se combinan y publican. Las correcciones posteriores al lanzamiento o las actualizaciones de seguridad se resumen en las publicaciones del blog.
Cómo un administrador de versiones crea parches
Usamos GitLab CI y otras funciones como ChatOps para generar parches. El administrador de versiones activa el lanzamiento de la solución activando el equipo ChatOps en nuestro canal interno. #releases en holgura.
/chatops run release prepare 12.10.1ChatOps funciona dentro de Slack para desencadenar diferentes eventos, que luego GitLab procesa y ejecuta. Por ejemplo, el equipo de entrega configuró ChatOps para automatizar varias cosas para lanzar parches.
Una vez que el administrador de versiones inicia el equipo ChatOps en Slack, el resto del trabajo se realiza automáticamente en GitLab usando CICD. Existe una comunicación bidireccional entre ChatOps en Slack y GitLab durante el proceso de lanzamiento, ya que el administrador de lanzamiento activa algunos de los pasos principales del proceso.
El siguiente video muestra el proceso técnico de preparación de un parche para GitLab.
Cómo funciona la implementación automática en gitlab.com
El proceso y las herramientas utilizadas para actualizar gitlab.com son similares a los utilizados para crear parches. Actualizar gitlab.com requiere menos trabajo manual desde el punto de vista del administrador de versiones.
En lugar de ejecutar implementaciones utilizando ChatOps, utilizamos funciones de CI, p. , con el cual el gestor de lanzamientos puede programar determinadas acciones a realizar en el momento requerido. En lugar de un proceso manual, hay una canalización que se ejecuta periódicamente una vez cada hora y que descarga los nuevos cambios realizados en los proyectos de GitLab, los empaqueta y programa la implementación, y ejecuta automáticamente pruebas, control de calidad y otros pasos necesarios.
"Así que tenemos muchas implementaciones ejecutándose en diferentes entornos antes de gitlab.com, y después de que esos entornos estén en buenas condiciones y las pruebas muestren buenos resultados, el administrador de versiones inicia las acciones de implementación de gitlab.com", dice Marin.
La tecnología CICD para admitir actualizaciones de gitlab.com automatiza todo el proceso hasta el punto en que el administrador de versiones debe iniciar manualmente la implementación del entorno de producción en gitlab.com.
Marin entra en detalles sobre el proceso de actualización de gitlab.com en el siguiente vídeo.
¿Qué más hace el equipo de entrega?
La principal diferencia entre los procesos de actualización de gitlab.com y el lanzamiento de parches a los clientes internamente es que este último proceso requiere más tiempo y más trabajo manual por parte del administrador de lanzamientos.
"A veces retrasamos la publicación de parches a los clientes con sus instalaciones debido a problemas reportados, problemas con las herramientas y porque hay muchos matices que deben tenerse en cuenta al lanzar un solo parche", dice Marin.
Uno de los objetivos a corto plazo del equipo de entrega es reducir la cantidad de trabajo manual por parte del administrador de lanzamientos para acelerar el lanzamiento. El equipo está trabajando para simplificar, agilizar y automatizar el proceso de lanzamiento, lo que ayudará a solucionar problemas de baja gravedad (S3 y S4, aprox. traductor). Centrarse en la velocidad es un indicador clave de rendimiento: es necesario reducir el MTTP (el tiempo desde la recepción de una solicitud de fusión hasta la implementación del resultado en gitlab.com) de las 50 horas actuales a 8 horas.
El equipo de entrega también está trabajando en la migración de gitlab.com a una infraestructura basada en Kubernetes.
Nota del editor: Si ya has oído hablar de la tecnología Kubernetes (y no tengo ninguna duda de que sí), pero aún no la has tocado con las manos, te recomiendo participar en cursos intensivos online. , que se llevará a cabo del 28 al 30 de septiembre, y , que tendrá lugar del 14 al 16 de octubre. Esto le permitirá navegar y trabajar con confianza con la tecnología.
Se trata de dos enfoques que persiguen el mismo objetivo: entrega rápida de actualizaciones, tanto para gitlab.com como para los clientes en sus instalaciones.
¿Alguna idea o recomendación para nosotros?
Todos son bienvenidos a contribuir a GitLab y agradecemos los comentarios de nuestros lectores. Si tienes alguna idea para nuestro equipo de reparto, no lo dudes. marcado team: Delivery.
Fuente: habr.com