DevOps serie CI/CD en SAP BTP (Parte 7)
Esta es una serie de entradas para configurar y deployar de manera eficiente mediante SAP BTP nuestras aplicaciones.
Hasta ahora las operaciones las hemos disparado de manera manual, pero la gracia es que la construcción del MTAR funcione de manera automática, en este post vamos a automatizar el lanzamiento.
Tabla resumen de contenido
Añadiendo triggers SAP Continuous Integration and Delivery para construcción automática
Ahora que ya tenemos todos los controles añadidos vamos a automatizar la generación del MTAR para que cuando detecte una modificación en GIT nos lance el proceso.
Este triggers se dispara con un concepto llamado Webhooks. Esto no es mas que un servicio de los repositorios GIT que mandan un mensaje a quien les este escuchando (es decir, cualquier servicio de CI/CD).
Trigger mediante webhook
Esta es la opción recomendada ya que nos permite iniciar la construcción solo en el momento que se envía la señal de cambio des de GitHub.
Creando un webhook en SAP Continuous Integration and Delivery
Vamos a nuestro JOB de SAP Continuous Integration and Delivery para activar el receptor:
Ya solo nos queda obtener los datos de conexión, para ello, pulsamos en el boton de «…» y el botón «Webhook» data.
Los datos que nos aparecen los necesitaremos en el próximo paso.
Conectando el webhook con GitHub
Ahora activamos en GitHub el servicio webhooks, vamos a nuestro repositorio y activamos el servicio:
Y añadimos en la configuración que nos solicita Github los datos del paso anterior.
Esta es una configuración de ejemplo, esta claro que la url y la clave es la que es, pero el punto donde podéis jugar es el evento que os disparara el webhook. Es este caso cada vez que pase algo en nuestro repositorio. Cuando lo tengamos pulsamos «Add webhook».
Y este es el resultado:
Vemos que al hacer el push al repositorio de GitHub se inicia la construcción:
Y vemos como del commit que hemos hecho se inicia la construcción:
Trigger mediante JOB (Alternativa)
Esta alternativa es menos recomendable, ya que en verdad un job validará si hay cambios cada X tiempo y en caso que sea así empezará con la construcción. Aun así esta opción tiene mucho sentido en entornos de desarrollo y ramas de desarrollo para que así podamos acumular unos cuantos commits antes de iniciar la construcción.
Un dato importante es que estos Jobs son compatibles también con la opción anterior.
Para activar estos JOBS y estando sin editar el job (esto es muy importante) nos aparece la opción de añadir un nuevo job:
Al pulsar add, tenemos que informar dos opciones, una es el nombre de la rama a «controlar» y el patron del cronometro:
Un desplegable nos ayudara con el cronometro pero resumiendo utiliza 5 caracteres, cada uno es una unidad temporal que va de mas corta a mas larga. Esto significa que el primer carácter de la izquierda son los minutos, el siguiente las horas, luego días, messes y el último es el día de la semana concreto.
Con el carácter «*» indicamos algo parecido a «en cualquier momento», luego cada posición podemos añadir números. Incluso podemos hacer divisiones. Así por ejemplo. si queremos que se lance un job los viernes cada 15 minutos usaríamos este patron: «*/15 * * * 6».
Este post corresponde a una serie de post relacionados con DevOps y en concreto con la parte de CI/CD. Si te ha gustado suscribete, dale a la campanita de notificaciones y comparte en redes para estar a la última. Vota Like / Dislike para aportar feedback.
