Cuando implementamos el flujo de despliegue basado en Trunk, nuestra pipeline a prod se aceleró mucho. Esto fue realmente genial, pero al mismo tiempo, estábamos produciendo más código del que el equipo de QA podía manejar, previniéndonos de desplegar features específicos a producción si algo ya estaba en la cola. De alguna manera resolvimos esto creando despliegues de feature branch, pero el problema era que los devs mergeaban a QA en lugar de desplegar a los ambientes de testing, causando el problema de nuevo.

En algún punto, decidí tomar acción en este asunto, ya que el CTO se había quejado de esto varias veces en el pasado, y era tiempo de resolverlo. Después de unas pocas horas de evaluar nuestro proceso de despliegue, me di cuenta de que nuestro problema era no dar suficiente participación al equipo de QA en el proceso. QA estaba a cargo de testing E2E y automatización pero no estaba directamente involucrado en los despliegues.

Al día siguiente, durante nuestra daily meeting, señalé mis hallazgos y dije que, para prevenir cualquier problema futuro, lo que necesitábamos era empoderar al equipo de QA dándoles más participación y poder de decisión con respecto a los despliegues. El viejo proceso estaba enfocado en devs, ya que somos los dueños de las tareas desde el momento en que las movemos de TO DO hasta que la definición de Done se cumple.

En lugar de que los devs decidieran cuándo mergear algo en master, lo que propuse fue que después de la aprobación del code review, las tareas son asignadas a QA, y ellos deciden qué hacer: ya sea mergearlo en master y testearlo en el ambiente de QA si consideran que es suficientemente simple para testear, o desplegar un ambiente de feature branch para features más complejos. Este pequeño cambio garantiza que nuestro proceso funciona sin problemas al permitir que QA decida cuándo algo está listo para salir. En el momento en que QA dice que está bien para salir, pueden inmediatamente promoverlo a producción.

Otro cambio agradable introducido fue dar más contexto a los QAs al compartir los PRs con ellos y, en algunos casos, asignar el code review a ellos en lugar de a un dev senior. Obviamente, no todos los PRs son asignados a ellos para code review, pero ahora están al tanto de qué se trata el cambio y el impacto que tiene. En el pasado, algunas de mis tareas fueron reasignadas a mí porque QA reclamaba que mi código hacía el checkout u otra parte importante del sitio web inaccesible, pero la mayoría de las veces, nos dimos cuenta de que esos problemas ya estaban en producción pero nadie los había reportado hasta ese momento.

Para que todo coincida, lo que hacemos es usar el Task ID como el nombre de la branch. De esa manera, QA puede encontrar y leer el código, decidir qué hacer para testing, y, finalmente, mergearlo a master y desplegar. A pesar de que el equipo de QA ahora es responsable de desplegar nuevos features, todavía es responsabilidad de los Devs asegurarse de que sus tareas cumplan con la Definición de Done.

Es genial ver cómo, al introducir pequeños cambios a nuestro proceso de despliegue, fuimos capaces de remover los problemas que estábamos experimentando y que el equipo de QA puede participar más activamente durante el proceso, agregando más valor al negocio.