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:
- Crear una nueva rama para implementar la nueva feature
- Realiza todos los commits necesarios para esta nueva rama
- Cuando termines de desarrollar la nueva feature, se crea un nuevo PR para fusionarse con una rama (development, master, …)
- 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:
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! 🙂
