Todo lo que no sabías sobre Automation for Jira Cloud

Llegados a este punto, seguro que ya llevas bastante tiempo disfrutando de todas las ventajas de Automation para Jira Cloud.  Gracias a este complemento integrado en nuestras instancias podemos conseguir automatizar procesos de un forma relativamente rápida y sin escribir nada de código, por lo que prácticamente cualquiera puede crear automatizaciones en unos pocos clics.

Pero, ¿sabes realmente todo lo necesario para crear reglas de Automation? ¿Quieres conocer los mejores consejos para que no se te pasa nada? ¿Sabes cuáles son los errores más comunes? En este artículo resumimos toda esta información y mucha más. Para que realmente disfrutes de Automation y puedas sacarle el máximo partido posible.

Detalles de una regla de Automation

Para crear una regla de automatización, solamente tenemos que acceder al menú donde está las automatizaciones, buscar el botón en el ángulo superior derecho, y hacer clic en él.

Lo que no se suele conocer demasiado es la información que vienen en el menú «Detalles de la regla» , además de los límites de Automation. Porque sí, Automation for Jira tiene limites y tenemos que conocerlos para evitar errores que más adelante nos obligarán a «re-trabajar».

Para ver los detalles de la regla, solo tenemos que hacer clic en el enlace situado a la izquierda del menú principal.

Ahora veremos las opciones que nos presenta la herramienta:

Nombre: Tenemos que ponerle un nombre para poder identificarla fácilmente en el menú principal. Es obligatorio pero además muy recomendable que sea un nombre fácilmente comprensible por cualquier usuario.

Descripción: Es interesante rellenar este campo porque con el paso del tiempo, tendremos muchas automatizaciones y es bueno saber qué hacen exactamente sin tener que ponernos a interpretar la Automatizacion.

Alcance: Nos indica a qué proyecto o proyectos aplica. En esencia, tenemos dos tipos. Individual, que aplica solo a un proyecto y el resto (Todos los proyectos, Múltiples proyectos, Tipo de proyecto)

Permitir desencadenador de regla: Esta opción hay que marcarla si quieres que la automatización arranque en respuesta a otra regla. Por defecto está desconectada.

Notificar al producirse un error: Tenemos tres opciones.

• La primera nos enviará una notificación al propietario si la regla falla siempre que, en la ejecución anterior, funcionase. (Recomendada)
• La segunda opción, también nos enviará una notificación al propietario siempre que falle, la diferencia es que si empieza a fallar repetidamente, con la primera opción solo recibiremos un mensaje y con la segunda, tantos mensajes como ejecuciones fallidas.
• Con la tercera opción, no nos notificaría.

Propietario: Es la persona que recibirá los mensajes de correo electrónico cuando la regla no funcione correctamente. Es la persona que ha creado la regla.

Agente: Es el usuario que realizará los cambios ejecutados por la regla, por lo tanto será el usuario que veremos en el log realizar las tareas.

¿Quién puede editar esta regla?: Aquí también tenemos tres opciones.

• Privado , es decir, que solo yo puedo editar la regla.
• Administradores específicos, es decir , seleccionaremos quién puede editar la regla.
• Todos los administradores. En esta opción todos los administradores de Jira y de este proyecto, podrán editar la regla.

Una vez completada esta información ya podríamos empezar a construir nuestra regla.

Límites en la ejecución de una regla

Otro punto muy importante son los límites de ejecuciones. Es vital conocer qué límite de ejecución tenemos para poder controlar correctamente si creamos reglas por proyecto o reglas globales y en qué casos.

Para las reglas globales, además de los límites que veremos ahora, tenemos un límite de ejecución y de alcance, definido por el tipo de plan ( lo podéis ver aquí https://support.atlassian.com/jira-cloud-administration/docs/explore-jira-cloud-plans/ en la parte de Automation) y el número de licencias.

Para acceder a este número de ejecuciones globales, hay que acceder desde la pantalla principal de Automation y buscar el menú «Uso». Desde aquí podremos ver el numero de ejecuciones que hemos consumidas y las totales.

Podemos encontrar el detalle haciendo clic en «Ver datos»

En este caso tenemos muchas ejecuciones disponibles, pero nos podemos encontrar otros casos, con un límite mucho más bajo. Por eso, antes de generar reglas globales tenemos que calcular cuándo se lanza la regla porque, aunque no modifique nada, porque no coincida las condiciones, la ejecución cuenta para este total.

Es decir, si genero una regla global, que se lance cuando se cree un ticket, aunque tenga una condición que diga que el issuetype tiene que ser bug, lo que realmente cuenta, es que se va a lanzar siempre que se cree un ticket, independientemente de que cumpla las condiciones o no.

Limitaciones a la hora de crear reglas de automation

Una vez entendido esto, vamos a ver otra limitación que tienen las automatizaciones. Podéis encontrar más información aquí https://support.atlassian.com/cloud-automation/docs/automation-service-limits/

• Componentes por regla. Tenemos un limite de 65 componentes por regla. Es decir, sumando condiciones, ramificaciones y acciones, no podemos pasar de 65. El problema viene cuando estás construyendo una regla y la herramienta no te informa que te has pasado de 65 componentes. El error lo recibirás una vez guardad la regla.  Es decir, podemos escribir una automatización de 80 líneas y cuando vamos a guardarlo, encontrarnos que tenemos que hacerlo más pequeño porque hemos superado el límite. El consejo sería no hacerlo de mas de 50 componentes para que, si más adelante tenemos que realizar pequeños cambios, poder hacerlos sin tener que rehacerlo o escribir una automatización complementaria a la original. Se pierde mucho tiempo en eso y serían más ejecuciones para el conteo general.
• Nuevas subtareas por regla. A veces, el esfuerzo de la tarea tiene que ser dividido en tareas mas pequeñas. Se suele dividir porque la tarea es demasiado grande o porque la tarea va a ser repartida entre varias personas. Para ello, utilizaremos las subtareas. Tenemos la posibilidad de crear subtareas desde una regla.  Pero ojo, porque existe la limitación de crear solo 50 subtareas por regla.
• Búsqueda de issues. Si queremos hacer cambios masivos de varias issues, es muy fácil hacerlo con Automation.  Pero una vez más hay que tener en cuenta la limitación que tenemos en una búsqueda: la automatización solo aplicará a 1000 tickets. Es decir, si hago una jql en Automation para modificar 2008 tickets, la regla solo modificará los 1000 primeros tickets. La solución para modificar, estos 2008 tickets, pasará por crear 3 automatizaciones iguales e irlas ejecutando secuencialmente. (Una para los mil primeros, otra para los mil segundos, y otra para los ocho restantes).
• Ejecuciones simultáneas: Si tenemos una regla que se ejecuta cada cinco minutos por ejemplo, y por algún motivo, esta regla tarda más de cinco minutos en terminarse, la siguiente no se ejecutará . Mientras tenemos una regla ejecutándose, no se volverá a ejecutar, mientras la «primera» siga corriendo.
• Tareas asociadas a issues: Como ya recordamos antes con una jql solo podremos modificar las 1000 primeras issues. Pero nos podemos encontrar alguna regla que modifique la subtarea, en este caso el limite serán 5000. Es decir: Si tenemos una jql que aplica a 500 issues y a sus subtareas, teniendo cada issue 10 subtareas, estaríamos justo en el limite para que la regla nos funcionase (500×10=5000). En cambio, si tenemos una jql que aplica a 600 issues y a sus subtareas, sabiendo que cada issue tiene 10 subtareas, nos pasaríamos del limite de 5000. (600×10=6000).
• Elementos globales encolados: Solo podemos tener en ejecución a la vez, reglas que apliquen a un máximo de 50.000 tickets.
• Tiempo de procesamiento diario: 60 minutos cada 12 horas. Esto quiere decir que, ejemplo, si tenemos una regla que salta cada diez minutos y tarda en finalizarse cinco minutos, a las dos horas nos empezará a fallar, y seguirá haciéndolo durante las próximas 10 horas.
• Detección de bucle: Si se detecta que la regla se está ejecutando sin sentido, porque no hemos sabido configurarla correctamente, a las 10 ejecuciones se marcará como LOOP y será detenida.
• Envío de correos: Si tenemos una versión gratuita o una de prueba, solo podremos enviar 100 correos cada 24 horas.

Si fuéramos notificados de un error, tendríamos que acceder al «Audit Log» de la regla y verificar. En la captura de pantalla del ejemplo, podemos observar que nos hemos pasado del límite. En el estado encontraremos «Throttled» y en los detalles encontraremos el error.

Para la mayoría de los límites, lo único que podemos hacer para que no fallen, es conocerlos para poder evitarlos, pero para el «tiempo de procesamiento diario», además,  tenemos una opción en el propio automation, que nos notificará, si así lo queremos, que la regla va a llegar al limite.

Para ello nos vamos al menú de Automation y buscamos la opción «Límites de servicio incumplidos».

Seleccionamos cuando queremos que se ejecute. Podemos elegir un 80% o un 90% de los límites de servicios usados o que salta una vez sobrepasemos los límites de servicio. La frecuencia: una por hora, una cada 12 horas o una vez al día. Y, por ejemplo, el correo donde queremos que se nos notifiquen estos límites.

Duplicar los componentes de una regla

Por terminar con una funcionalidad que os va a ahorrar mucho tiempo y que Atlassian ha incorporado recientemente (Marzo 2023), ahora sí, ya podemos duplicar los componentes de una regla de Automation.

Hasta ahora, cuando necesitábamos duplicar cualquier componente, teníamos que hacerlo de forma manual. Lo que en algunas reglas con muchas acciones, suponía una labor bastante tediosa.

Gracias a esta nueva opción , podemos crear copias de un componente configurado con un solo clic. Cuando duplicas uno de los componentes con esta acción, se mantiene la configuración del componente original exactamente igual.

El icono de «Duplicar» se encuentra en cada uno de los componentes:

Sin duda, una muy buena noticia para todos aquellos que pasamos muchas horas configurando reglas de Automation complejas y con muchos componentes similares.

Espero que os haya servido de ayuda. Ojalá hubiera encontrado este artículo en alguna documentación antes de tropezar con alguna de estas piedras. Ahora espero que vosotros no tropecéis en las mismas.

Seguiremos compartiendo información útil para hacer la vida de los administradores de Jira mucho más sencilla 🙂