Después de varias iteraciones en nuestros pipelines llegamos a un punto en el que todo está funcionando sin problemas y la mayoría de las nuevas mejoras están relacionadas con la optimización, como reducir 1 minuto por paso al reducir los tamaños de las imágenes Docker o algo más que pueda considerarse una mejora real para nuestro flujo.

Como somos un Super Equipo Internacional, algunos de los miembros del equipo comienzan a trabajar antes que otros, esto no es un problema para nosotros, ya que estamos más enfocados en el valor que agregamos al negocio que en contar cuánto tiempo pasamos sentados frente a la computadora. El otro día, durante nuestra reunión diaria, estaba escuchando una conversación sobre quién era responsable de desplegar los feature environments - Estos entornos se eliminan todos los días para evitar costos inesperados - y parece que les estaba costando decidir quién necesitaba desplegar el entorno cada mañana, para resumir la historia, llegaron a un acuerdo y lo hicieron funcionar.

Mientras tanto, yo estaba en segundo plano tratando de entender cómo hacer la vida más fácil a todos, ya que tal vez otros usuarios no técnicos podrían necesitar validar una feature, pero el Desarrollador no está presente. Esto no es algo que suceda a menudo, pero descubrí que nuestros deployments podrían acelerarse también con esto.

Mi propuesta fue simple, crear un comando en Slack que permita a los usuarios desplegar feature branches cuando sea necesario.

¿Por qué Slack?⌗

¿Y por qué no? Es fácil para mí acceder a nuestro pipeline y desplegar el branch como lo construí, pero para los usuarios no técnicos será complejo y no realizarán esas acciones con demasiada frecuencia, además Slack es la app que usamos todos los días para la comunicación y todos están acostumbrados a ella.

Puede que estés pensando que permitir a todos los usuarios en slack usar un comando y desplegar tantos entornos como quieran sería un desastre y de hecho lo es. Para evitar cualquier complicación, solo los usuarios en un determinado canal pueden ejecutar el comando, el canal es privado y solo los que realmente necesitan acceso a él están invitados.

Para crear el comando Slash en Slack, necesitarías crear una App primero y luego crear el comando. Al crear el comando, se pide un nombre, el webhook que va a manejar la solicitud, una breve descripción y una sugerencia para Slack.

Después de configurar todo, la vista previa del comando será similar a la siguiente imagen:

Por lo general, estas mejoras no son una prioridad para el negocio, pero el valor para el equipo es alto, basado en esa declaración, “Desperdiciar” tiempo en crear un backend para administrar las solicitudes está fuera de alcance y lo que hice fue usar una Low Code app que he estado usando para mis automatizaciones personales, en este caso uso N8N, pero hay muchas como, Zapier, Make, Pipedream o Node-RED.

Arrastrando y soltando algunas tareas predefinidas, pude construir el backend requerido y también gestionar algunas excepciones como un proyecto seleccionado incorrecto, que el branch no exista o si el comando fue ejecutado en un canal que no está permitido.

N8N es una forma genial de administrar pequeños workflows en poco tiempo y lo mejor es que está totalmente dockerizado, lo que hace que sea rápido de instalar y luego crear el workflow. Sobre la seguridad, puedes estar seguro porque un atacante necesitaría el endpoint específico y también la firma de slack de la app que también se valida.

Las opciones para este tipo de herramientas son ilimitadas, también tenemos un backend de detección temprana de fraude basado en nuestro proveedor de pasarela de pago y las notificaciones de fraude son procesadas por N8N y también notifica al equipo a cargo.

En resumen, esta es una forma rápida y fácil de agregar valor a tus proyectos al empoderar al equipo para que tome acciones basadas en sus requerimientos, pedir a un Desarrollador que despliegue un entorno puede que no suene como demasiado, pero el verdadero problema aquí no es cuánto tiempo les toma a los Devs desplegar el entorno, sino el tiempo que toma recuperar el mismo ritmo y enfoque perdido cuando reciben la solicitud. Esto no es algo que me inventé, por favor siéntete libre de echar un vistazo a esta publicación:

[!cite] Se necesitan 23 minutos para entrar en un estado de flujo