Jenkins X preview environments

 In CICD, Jenkins X, Kubernetes

Esta es la segunda publicación sobre Jenkins X de una serie de publicaciones que escribiremos. Hace algunas semanas, escribimos una publicación introductoria sobre lo qué es Jenkins X y cómo puede ayudarte a implementar tu aplicación en un clúster de kubernetes.

Esta vez hablaremos sobre una característica de Jenkins X llamada preview environments y lo útil que es para probar nuevas características antes de fusionarlas con otra rama.

Si usas gitflow en tu empresa, Jenkins X puede ayudarte a administrar todo el flujo que propone esta metodología. Recientemente, hemos sido invitados a ser speakers en un meet up organizado por la comunidad de Spainclouds donde hablamos sobre Gitflow y Jenkins X. Aquí puedes ver la sesión grabada.

Entornos Jenkins X

Jenkins X, dispone de 3 tipos de entornos de 2 modalidades distintas:

  • Entornos Estáticos
    • Staging
    • Production
  • Entornos efímeros o dinámicos
    • Entorno Preview

Por supuesto, puedes crear tantos entornos estáticos como necesites para satisfacer las necesidades de tu equipo/empresa (por ejemplo, para implementar una estructura de ramas basada en gitflow), pero esta vez hablaremos sobre entornos preview; cómo funcionan y cómo pueden ayudarnos.

Los entornos preview son efímeros. Eso significa que se crean dinámicamente para cada PR y se destruyen cuando se cierra este PR. Al hacer esto, todos los recursos necesarios solo se crean y usan estrictamente cuando los necesitamos.

Entornos Preview

Para explicar esta característica de Jenkins X, asumiremos que solo tenemos entornos de Staging y Productión.

Imaginemos que necesitas desarrollar una nueva feature. Estos son los pasos que probablemente harás:

  1. Crear una nueva rama para implementar la nueva feature
  2. Realiza todos los commits necesarios para esta nueva rama
  3. Cuando termines de desarrollar la nueva feature, se crea un nuevo PR para fusionarse con una rama (development, master, …)
  4. Después de revisar el código, realizar pruebas unitarias, etc…, finalmente estará listo para fusionarse en la rama deseada

¡Genial! Vamos a explicarte qué hace Jenkins X para crear el entorno preview:

JenkinsX preview environment creation

Figure 1: JenkinsX: creación del entorno preview

Cuando Jenkins X detecta que has creado un nuevo PR para fusionar tu rama, JenkinsX arranca una pipeline que crea un namespace específico en tu clúster de kubernetes con todos los recursos necesarios para ejecutar y exponer tu pod con el contenido de la rama.

La pipeline que ejecuta Jenkins X es una pipeline predefinida en los Jenkins X buildpacks y depende del lenguaje usado en tu aplicación. Por supuesto, puedes modificar estas pipelines predefinidas para cumplir con tus necesidades (agregar o modificar pasos, pruebas, …) pero hablaremos de eso en otra publicación. 😉

Cuando Jenkins X termina, puedes ver algo como esto en tu clúster de kubernetes:

bash~$ kubectl get pod -A | grep preview
NAMESPACE                   NAME                               READY   STATUS      RESTARTS   AGE
jx-mycompany-jxqsapp-pr-16  preview-preview-7d48fd5f6-9fjlz    1/1     Running     0          23m

Y estos son todos los recursos creados dentro de este namespace efímero.

bash~$ kubectl get all -n jx-mycompany-jxqsapp-pr-16
NAME                                  READY   STATUS    RESTARTS   AGE
pod/preview-preview-7d48fd5f6-9fplz   1/1     Running   0          31m

NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
service/jxqsapp   ClusterIP   10.110.76.143                  80/TCP    31m

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/preview-preview   1/1     1            1           31m

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/preview-preview-7d48fd5f6   1         1         1       31m

Cuando finaliza la pipeline preview, Jenkins X expone tu entorno preview configurando un ingress controller y crea un comentario en tu PR de Github con esta información:

Jenkins X crea un enlace que apunta a la URL del entorno preview creado para este PR.

Una vez que el PR se fusiona con master, Jenkins X implementa esta versión en el entorno de staging para finalizar todos los pasos de prueba / integración. Finalmente, el último paso, será subirlo al entorno de producción.

Un entorno preview tiene como principales beneficios:

  • Permite a los desarrolladores colaborar y validar los cambios antes de que se integren nuevamente en el codebase
  • Prueba el PR desplegado en un clúster de kubernetes real antes de realizar el merge
  • Aumenta la confianza antes de subir el código a producción
  • Crea una URL accesible para permitir UAT antes de realizar el merge
  • Garantiza las best practices en testing

¿Quieres implementar Jenkins X en tu empresa? Te podemos ayudar. ¡Contáctanos and Feel the Geko Way! 🙂

Recommended Posts

Leave a Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.