Como nuestro equipo de entrega, utilizando solo nuestros propios recursos, rehicimos nuestro sistema bajo CI / CD.
Los equipos de ingenieros están constantemente bajo presión: debe proporcionar nuevas funciones en forma de un producto digno y, al mismo tiempo, minimizar constantemente el tiempo de ciclo . A menudo, los expertos sin comprender las herramientas modernas. La integración y entrega continua (CI / CD) está integrada en GitLab, nuestra única aplicación de ciclo de vida DevOps, y ahora estamos migrando a Kubernetes para reducir aún más el tiempo de ciclo. Sin embargo, para el CI / CD, y finalmente Kubernetes, fuimos de una manera bastante inusual. El equipo de Delivery , que nos cambió a la entrega continua de GitLab.com, tensó el sistema anterior y solo entonces cambiamos completamente a Kubernetes.
Cómo lanzamos lanzamientos antes de CI / CD
Entre el 7 de agosto y el 27 de septiembre de 2019, la gran comunidad de GitLab y los miembros de nuestro equipo alcanzaron un promedio de 55 confirmaciones por día; estas son iteraciones continuas de nuestro producto para crear nuevas funciones. Pero antes de dominar la entrega continua, utilizamos períodos de congelación de nuevas funciones a partir del 7 de cada mes: en este momento, nuestros ingenieros cambiaron su atención del desarrollo de nuevas funciones a la depuración para preparar los próximos lanzamientos que saldrán de manera estable el 22 de cada mes.
Al introducir una fecha límite estricta, inculcamos a los desarrolladores un comportamiento que los ayudó a centrarse en una fecha específica, en lugar de centrarse en la preparación.
"... los desarrolladores comenzaron a bailar desde la séptima fecha, porque miraron el calendario y pensaron: bueno, todavía hay tiempo, el séptimo día de la semana, y luego, a la medianoche del 6, se fusionaron frenéticamente", dijo Marine Jankowski , CTO del equipo de entrega. "Saben que si rompen los plazos, tendrán que esperar otro mes, y si logran hacerlo a tiempo, tendrán dos buenas semanas más para depurar".
Desde el inicio de GitLab.com, los períodos de congelación de nuevas funciones se han utilizado como tiempo para estabilizarse ", explicó Marine.
Sin embargo, el número de usuarios fue creciendo y la necesidad de nuevas características nos obligó a acelerar el ritmo de desarrollo. El período de estabilización ralentizó el ciclo y retrasó en gran medida la transición a la depuración, la regresión y la entrega de funciones, tanto a los usuarios de Gitlab.com como a los clientes individuales.
"En algunos casos, [congelar nuevas funciones] incluso provocó la inestabilidad de la plataforma, debido al hecho de que las soluciones de alta prioridad no llegaron al cliente a tiempo", dijo Marine. - "Al cambiar a CI / CD, entregamos nuevos productos y los depuramos mucho más rápido".
Antes de formar el equipo de entrega para mover GitLab.com a la entrega continua , y en última instancia a Kubernetes, dependíamos del administrador de la versión . Esta era una posición de transición entre los desarrolladores que ocupaba el que estaba preparando el nuevo lanzamiento. Hemos estado iterando el proceso durante más de 5 años , pero los gerentes de lanzamiento han creado una base de conocimiento y la han automatizado más o menos.
Sin embargo, el método resultó ser ineficaz, porque el calendario de implementación y la preparación para el lanzamiento flotaron: de medio día a varios días debido al hecho de que las tareas para la ejecución manual se estaban acumulando en el proceso .
"El administrador de versiones recibió una lista fija de tareas, una fecha límite y repitió los pasos anteriores una y otra vez hasta que se obtuvo una versión completamente lista y estable en GitLab.com", dijo Marine. En el sentido más general, el administrador de versiones requería lo siguiente:
- Sincronización manual de los muchos repositorios que componen GitLab.
- Asegúrese de que las versiones correctas estén incluidas en las ramas de Git creadas manualmente.
- Cuando la versión reciba las etiquetas, implemente manualmente los entornos de prueba y producción en GitLab.com.
- Asegúrese de que todo funcione y publique manualmente paquetes para usuarios individuales.
En una presentación en Brooklyn durante el GitLab Commit dedicado a este tema, Marine compartió los resultados de las observaciones para 2018: en el período de dos semanas antes del lanzamiento, el equipo de Delivery pasó el 60% del tiempo interactuando con las implementaciones, otro 26% dedicado a tareas manuales y semi-manuales como escribir una revisión Lanzamiento mensual.
Resultados de observación para 2018, antes de pasar a la entrega continua: así es como el equipo de entrega pasó tiempo 2 semanas antes del lanzamiento.
"Hablando en general, luego 14 días, dos semanas antes del lanzamiento, el equipo solo hizo lo que estaba mirando a los monitores, observando cómo se secaba la pintura, o algo así", dijo Marine.
Pero asumiendo el 86% de este pastel (60% para implementaciones + 26% para tareas manuales), el equipo de entrega resolvería una serie de problemas:
- Nuevos lanzamientos sin demora.
- Implementaciones repetibles y más rápidas sin tiempo de inactividad.
- Más tiempo para migrar GitLab.com a Kubernetes.
- Más libertad para preparar su organización para la entrega continua.
Aunque el CD solo está disponible en GitLab.com, nuestros clientes individuales también se benefician de nuestra transición a él. Ahora, todo lo que no se ve afectado por las pruebas de CI se prueba de forma automática y manual en los entornos, antes de llegar a GitLab.com. Todo lo que llegue a GitLab.com y necesite depuración será depurado en unas pocas horas. Por lo tanto, el lanzamiento final para clientes individuales será limpio.
La transición de congelación a CD fue cuestión de tiempo, a medida que creció nuestra pila de funciones, y un equipo de ingenieros liderados por Marina pareció observar la transición: “El equipo de entrega se formó con el único propósito de transferir la compañía al modelo de CD y, al mismo tiempo, transferir la compañía a la plataforma Kubernetes para facilitar la ampliación y acelerar el ciclo ".
La mayoría de las compañías en lugar de GitLab comenzarían la transición a CI / CD y Kubernetes, primero integrando nuevas tecnologías en su flujo de trabajo y corrigiendo el proceso de desarrollo en el proceso. Hemos elegido un enfoque diferente.
La migración a Kubernetes requiere un cambio no solo en el sistema de producción, sino también en el enfoque de desarrollo ”, dijo Marine. Kubernetes ofrece ciertas funciones que están disponibles fácilmente y sin inversión adicional. Pero para beneficiarse realmente de las funciones gratuitas que ofrece Kubernetes, necesita algún tipo de CI / CD.
El equipo de entrega aceptó esto: para facilitar la transición a Kubernetes para la entrega continua, nuestros ingenieros ya deberían trabajar con un enfoque en CI / CD, lo que implica un mejor control de calidad (QA) y una planificación de funciones más estricta. Y luego nuestro equipo de entrega tomó una decisión sombría : construyó un sistema de CD con herramientas existentes y reorganizó la infraestructura de la aplicación GitLab.com, en lugar de dominar de inmediato las nuevas herramientas y tecnologías de CD.
"La idea era simple", dijo Marine, " utilizamos las herramientas a nuestra disposición , automatizamos la mayoría de las tareas manuales y probamos todo el sistema estático bajo carga. Si el sistema estático resiste, procedemos a la prueba dinámica".
Este enfoque proporcionó dos beneficios clave:
En primer lugar , hemos identificado todas las debilidades en nuestro enfoque y las hemos estabilizado mediante la automatización con CI, de modo que nuestra aplicación se ha fortalecido y el éxito de la transición a Kubernetes se ha vuelto más real.
En segundo lugar , al establecer un equipo de ingenieros en CD, implementamos en la mente de los ingenieros de GitLab, que están acostumbrados a implementaciones cada semana y esperan, a veces todo el día, ya que afectan la fusión, es un cambio cultural real.
"Desde que dominamos CI / CD, nuestros desarrolladores comenzaron a comprender de una nueva manera lo que significa hacerse", dijo Marine.
Antes de la introducción de CI / CD, el cambio se consideraba listo tan pronto como se completaba la revisión. Esto eliminó la implementación en varios entornos, lo que consumió mucho tiempo. Hoy, las implementaciones se entregan en unas pocas horas, por lo que no hay razón para no confirmar que los cambios estén operativos en entornos de prueba y producción.
La implementación de aplicaciones de revisión de Kubernetes permite a los desarrolladores ejecutar controles de calidad literalmente en tiempo real, y el uso de indicadores de características para una entrega progresiva también acelera el desarrollo.
"Desde el primer paso en el CD, los desarrolladores deben responder a cada control de calidad automatizado y también realizar confirmaciones manuales a un nuevo nivel en los entornos de producción y prueba. Además, los desarrolladores pueden realizar cambios en el entorno de producción en un día mientras que antes tomó varios días (o incluso semanas) ".
Con CD, puede realizar controles de calidad de código con mucha más frecuencia. Y dado que con nuestro sistema CI / CD, los cambios en el código se entregan las 24 horas del día, los desarrolladores rotan a pedido para cualquier problema no estándar que aparezca en tiempo real, ya que el "período de incubación" se ha reducido considerablemente.
Nuestro nuevo metodo
Habiendo implementado el sistema CI / CD , automatizamos el 90% del proceso. El 10% restante requiere intervención humana; se requiere coordinación entre muchas personas con derecho de acceso.
"Estamos reduciendo gradualmente este 10%, por lo que solo necesitamos aprobación para la publicación del lanzamiento", dijo Marine. En la iteración actual, el proceso de CI / CD funciona de la siguiente manera :
- CI busca automáticamente etiquetas específicas en solicitudes de fusión aprobadas por revisores y desarrolladores.
- CI sincroniza automáticamente los repositorios requeridos y al mismo tiempo crea las ramas, etiquetas Git necesarias, y también incluye las versiones de lanzamiento correctas que queremos entregar.
- Cuando se completan las compilaciones, los paquetes se implementan automáticamente en entornos de prueba.
- Se realizan controles de calidad automáticos y, si todo va bien, la implementación se entrega a un pequeño segmento de usuarios en un entorno de producción.
- Paralelamente, los desarrolladores llevan a cabo un control de calidad de un nivel diferente manualmente, para asegurarse de que las nuevas funciones funcionen como deberían.
- Si se descubre un problema de alta prioridad durante la confirmación manual, las implementaciones se detienen.
- Cuando se completa el paso anterior, el miembro del equipo de entrega comenzará la entrega de implementación para todos los usuarios de GitLab.com.
- Luego, en base a la última implementación de producción lanzada en GitLab.com, se crea una versión individual para el cliente.
Como con cualquier otro equipo de ingeniería, el escalado es un verdadero desafío para nosotros. Sin embargo, uno de los mayores desafíos para los técnicos es asegurarse de que el control de calidad cubra todo, pero para un proyecto grande como GitLab.com este es un trabajo intenso. Y también debe asegurarse de que haya suficiente monitoreo y notificación, para que el proyecto no funcione solo en reglas predefinidas.
El segundo gran desafío para nosotros es la complejidad del sistema GitLab.com y la transferencia de cambios en el proceso a todos los equipos de ingeniería. "Romper el proceso y los hábitos que se han establecido a lo largo de los años está lejos de ser fácil", dijo Marine.
Resultados
GitLab ya se beneficia mucho al cambiar a CI / CD.
Las observaciones y la evaluación en 2019 mostraron que en esos 14 días antes del lanzamiento, el equipo de entrega pasa el 82% del tiempo más productivo: se lo dejó libre para trabajar en otras tareas importantes.
La observación para 2019 mostró que en las mismas 2 semanas se liberó de los desarrolladores un tiempo tan precioso gracias a la transición a c CD.
Al automatizar el trabajo manual, el equipo de Delivery finalmente cambió a cambiar la infraestructura de GitLab.com para mejorar el soporte para la velocidad de desarrollo y el tráfico de usuarios, y al mismo tiempo, la migración a Kubernetes.
"Y, como ya he dicho, todo esto es sin Kubernetes. Todo se hizo en el antiguo sistema predecesor", dijo Marine a los invitados del Brooklyn GitLab Commit. - "Pero ganamos el tiempo, así que ahora mi equipo está muy involucrado en la migración. Sin embargo, uno de los mayores cambios ocurrió precisamente en el hábito de organizar el desarrollo".
Los resultados después de la transición son significativos. Si en el sistema anterior en mayo de 2019 el equipo entregó 7 implementaciones, en agosto de 2019 esta cifra aumentó a 35. Y este no es el límite: los números aumentarán significativamente, ahora que el equipo realiza muchas implementaciones diariamente.
"Acabamos de migrar nuestro Servicio de registro a Kubernetes, y si usa el registro de contenedores en GitLab.com , todas sus solicitudes se ejecutan en la plataforma de Kubernetes", dijo Marine. - "GitLab es un sistema de múltiples componentes, y continuamos aislando y transfiriendo otros servicios".
Cada nueva versión incluye nuevas funciones de CI / CD. Por ejemplo, en la versión 12.3, ampliamos el Registro de Contenedores GitLab, permitiendo a los usuarios usar CI / CD y recopilar e incrustar imágenes / etiquetas en sus propios proyectos . Hubo otras nuevas e interesantes innovaciones.
¿Transferir también el sistema a entrega continua?
Marin aconsejó a las compañías que están a punto de cambiar a CD para comenzar con lo que tienen.
"En cuanto a mí, estar sentado y esperar la migración a una nueva plataforma es dañarse", dijo Marine. "La mayoría de los sistemas se pueden cambiar de alguna manera y acelerar el ciclo de procesamiento sin migrar a un sistema completamente nuevo. Acelerar el ciclo de desarrollo / lanzamiento aumenta en gran medida la eficiencia de cada ingeniero en el sistema y libera más tiempo para migrar a una nueva plataforma, como Kubernetes".
Si tiene curiosidad acerca de lo que sigue, eche un vistazo a este resumen detallado de las nuevas y emocionantes funciones de CI / CD que esperan en las alas, con la versión 12.4 en adelante.
¿Te perdiste el Brooklyn GitLab Commit?
Si no pudo asistir a la presentación de Marina con los antecedentes de nuestra transición a Kubernetes, mire el video completo a continuación y únase a nosotros en el European GitLab Commit en Londres, el 9 de octubre .