Un desarrollador con cerca de 72 aplicaciones repartidas entre entornos de staging y producción describe el sistema que ideó para evitar la deriva entre ambos entornos y garantizar que cada cambio pase por staging antes de llegar a producción. El problema de partida era la ausencia de herramientas que hiciesen obligatorio ese paso, lo que con el tiempo provocó que staging quedase en desuso y los dos entornos se desincronizasen.
La solución es un conector, bautizado como bridge, que enlaza ambas mallas y permite que producción solicite a staging la compilación, las pruebas y el despliegue de cualquier componente. El diseño se apoya en un componente especial, proc-mesh, que se ejecuta sin privilegios, sin red y con un único socket Unix. La escalada de privilegios se realiza de forma puntual y auditada mediante doas, con reglas concretas para reiniciar servicios, verificar la base de confianza e instalar binarios firmados; el resto de componentes llevan NoNewPrivileges=yes, de modo que no pueden elevar privilegios ni acceder a la red una vez que lo hacen.
Gracias a esta arquitectura, el sistema conoce tanto la configuración esperada de cada aplicación como el procedimiento para desplegar una nueva, lo que permite re-sincronizar ambos entornos de forma masiva: cada app se stgea, se prueba y, solo si pasa los controles, se envía a producción dejando un registro auditable en cada etapa. El botón “Pull from staging” dispara ese flujo desde producción.
El autor reconoce una limitación: plug-mesh, el propio orquestador, no puede desplegarse a sí mismo y sigue usando el antiguo camino basado en runners de Gitea. La alternativa, probada en teoría, consistiría en levantar una nueva instancia sobre un puente NATS aislado entre mallas, validarla y, tras las pruebas, sustituir a la antigua. Su siguiente paso será un camino de despliegue más inteligente, con pruebas más rigurosas, que permita sustituir componentes sin detener los anteriores.