Explícame qué pasa entre que se fusiona un pull request y que ese código corre en producción en tu equipo.

Al hacer merge, CI ejecuta comprobación de tipos, lint, pruebas unitarias y de integración contra una base de datos real, y luego construye un artefacto inmutable etiquetado con el commit. Ese artefacto se despliega en staging automáticamente, corren pruebas de humo, y luego pasa a producción con un despliegue gradual con comprobaciones de salud y reversión automática. El comportamiento arriesgado va detrás de una feature flag, así que publicar código y lanzar una funcionalidad siguen siendo eventos separados.

En el último equipo en el que estuve, hacer merge a main lanzaba CI: comprobación de tipos, lint, pruebas unitarias y luego pruebas de integración contra un contenedor de Postgres, unos siete minutos de punta a punta. Si eso pasaba, construíamos una imagen de contenedor etiquetada con el SHA del commit, y esa imagen exacta es la que avanza; nada se reconstruye por entorno, porque entonces estarías entregando algo que nunca probaste. Se desplegaba en staging automáticamente, corría una suite corta de humo contra endpoints reales y luego pasaba a producción como despliegue rodante con comprobaciones de salud, vigilando la tasa de error y la latencia unos minutos con reversión automática si alguna cruzaba un umbral. Las migraciones corrían como un paso aparte antes del despliegue y siempre eran compatibles hacia atrás, así que revertir el código nunca dejaba el esquema colgado. Todo lo visible para el usuario salía detrás de una flag, apagada por defecto, luego para usuarios internos y luego para un porcentaje. Esa distinción importaba más que ninguna otra cosa, porque significaba que un mal lanzamiento era un interruptor de configuración y no un despliegue de emergencia a las nueve de la noche.