Creando Workflows reutilizables en Jenkins usando JTE.
Uno de los principales problemas que suelo encontrar cuando apoyamos las empresas para realizar su adopción DevOps, es que los pipelines tienden a ser repetitivos para varias de las aplicaciones de las compañías y esto hace que los Jenkinsfiles se copien de un proyecto a otro. ¿Qué ocurre si tenemos un nuevo paso en los pipelines que debe aplicar para todos?, ¿Qué puedo hacer para evitar que los equipos de desarrollo eliminen de los Jenkinsfiles pasos que son importantes como las pruebas unitarias o el análisis de código estático?, ¿Podría crear un template de pipeline para mi empresa que pueda ser usado sin tener que copiar y pegar código?; todas estas preguntas y algunas otras las resolvimos usando Jenkins Templating Engine (JTE) y en esta historia exploraremos un ejemplo del uso que puedes darle.
Jenkins Templating Engine (JTE)
Alguna vez (más o menos hace 3 años) cuando busqué con mi equipo de trabajo sobre como implementar templates en Jenkins para no tener que copiar y pegar los Jenkinsfiles de un proyecto a otro, encontramos que se podían usar las librerías compartidas de Jenkins para crear scripts que se reusaran entre los diferentes proyectos, en ese entonces implementamos una solución donde usamos esta tecnología con el fin de crear algunos templates para un sistema legacy con varias aplicaciones, facilitando la adopción DevOps del equipo y facilitando el manejo de los pipelines de manera centralizada, debemos tener en cuenta que en el proyecto trabajaban más de 300 desarrolladores y eran cerca de 30 proyectos de software entre monolitos y microservicios, en ese entonces el equipo fue premiado en el JenkinsWorld (como se conocía el evento en ese entonces) por su implementación.
Para este año (2020) estaba iniciando una nueva implementación similar a la explicada anteriormente y pensábamos hacer algo similar a lo que construimos en ese momento, sin embargo, en el espacio que siempre proponemos para investigar un poco antes de tomar una decisión, nos encontramos con JTE y vimos que es justo lo que hacíamos con las librerías compartidas de forma manual, listo en un plugin de Jenkins y con reglas específicas que facilitan la implementación y decidimos usarlo con muy buenos resultados. Algunas de las características que resalto de JTE son:
- Facilita el Gobierno Organizacional, permitiendo tener un proceso de delivery estandarizado.
- Optimiza el reuso del código permitiendo construir librerías para compartir entre los workflows.
- Facilita la mantenibilidad ya que podemos tener un único lugar donde realizar cambios que deben aplicar a todos (templates y librerías), o dejar la posibilidad de que se hagan personalizaciones para un proyecto especial (pipeline_config.groovy).
¿Cómo se usa?
En general consiste en escribir librerías de pasos que podrán ser usados por nuestros templates y que podrán ser específicas dependiendo de las tecnologías que usemos, por ejemplo podemos definir un template con los siguientes pasos:
El código del template sería algo como:
// file pipeline_templates/backends
unit_test()
static_code_analysis()
build()
deploy_to_dev()Y supongamos que este mismo template queremos usarlo tanto para proyectos Java como para proyectos Angular y Python, todo lo que tenemos que hacer es crear librerías para cada una de estas tecnologías donde se lancen los comandos correctos para cada caso y en cada proyecto importar la librería que aplica, por ejemplo para Java podríamos tener:
// file pipeline_config.groovy
libraries{
maven // suministra los pasos build y unit_test
sonarqube // suministra el paso static_code_analysis
weblogic // suministra el paso deploy_to
}y para Angular:
// file pipeline_config.groovy
libraries{
npm // suministra los pasos build y unit_test
sonarqube // suministra el paso static_code_analysis
s3 // suministra el paso deploy_to
}Debemos tener en cuenta que el file pipeline_config.groovy es un archivo que va en cada proyecto de software, tal como se hace con el Jenkinsfile, es un nuevo archivo de configuración de los pipelines que reemplaza el Jenkinsfile y permite que escribamos las configuraciones específicas de cada proyecto, por ejemplo el path donde queda el artefacto de despliegue no es el mismo en Java o Angular, estas rutas pueden ser configuradas en este archivo para que las librerías no dependan de las rutas.
Los templates van en un proyecto diferente que se configura en el plugin de la siguiente forma:
El job multibranch que configuremos para alguno de los proyectos quedaría de la siguiente forma:
Recalco nuevamente, todos los proyectos independiente de la tecnología siguen el mismo proceso y el único archivo que tiene cada proyecto es el pipeline_config.groovy donde se especifican las librerías que usará, así mismo si llega otro proyecto Java o Angular, es tan simple como crear el archivo de configuración del pipeline en el proyecto nuevo y crear el job, con esto ya el nuevo proyecto tendrá todos los pasos se definieran para nuestro proceso de Delivery.
Utilidades
En el siguiente repo puedes encontrar un proyecto base para crear tu propia librería:
En el siguiente repo puedes encontrar un proyecto con varias librerías implementadas y que puedes usar para no tener que iniciar de cero:
