Ayer estuve participando de un meetup donde Marcos Nils estuvo contando sobre su implementación de GitOps. Su presentación me pareció muy interesante pero lo que más me llamó la atención fue cuando comentó que en su organización no tienen ambiente de testing, ni staging, ni nada parecido, o sea: cada developer trabaja en su máquina, sube su código a Git y eso dispara una serie de pasos que terminan instalando una nueva versión en el ambiente productivo. No todos los pasos  son necesariamente automáticos, puede que haya algún trigger manual, pero el punto central es que la aplicación no es instalada en ningún otro ambiente más que el productivo.

Apenas escuché esto me resultó muy disruptivo, luego, en el intervalo hablé personalmente con Marcos y me siguió pareciendo disruptivo, ¡ja! Una estrategia de GitOps implica una alto de grado de automatización y el manejo de infraestructura como código, lo cual facilitaría mucho el armado de nuevos ambientes. Sin embargo, lo que me comentaba Marcos es que ellos hicieron un análisis y no encontraron la necesidad de un ambiente de prueba: tienen tests automatizados y algunas cosas las prueban directamente en producción utilizando usuarios particulares de forma de no interferir con los usuarios reales. La respuesta de Marcos me pareció razonable, pues tomaron las decisión con cierto fundamento y contando con toda una serie de medidas (automatización, monitoreo, alertas, etc) que les ayudan a mitigar algunos de los riesgos de no tener un ambiente de prueba.

Personalmente las veces en que me encontré con equipos/organizaciones sin ambiente de prueba, ha sido por la imposibilidad de armar dicho ambiente en lugar de ser consecuencia de una decisión analizada. Al mismo tiempo, en varios de los proyectos que he participado había un contexto de regulaciones que obligaban a contar con un ambiente de prueba/homologación, previo al ambiente productivo.

Pero quien sabe, tal vez algún día tenga la oportunidad de experimentar con una estrategia de este tipo.