DevOps resolvió este problema para el software hace años. No envía código directamente a producción. Desarrolla localmente, prueba en staging, promueve a través de puertas y despliega con revisiones. El patrón funciona porque detecta errores antes de que lleguen a los usuarios.
Los workflows de IA merecen la misma disciplina. Un cambio de prompt, un cambio de modelo, una nueva integración de herramientas — estos afectan la calidad del output de producción tanto como un cambio de código afecta el comportamiento de la aplicación. Pero la mayoría de las plataformas de IA tratan cada cambio como un cambio de producción. Edite un workflow, y está en vivo. Sin revisión. Sin staging. Sin red de seguridad.
La gestión de entornos de JieGou trae el pipeline dev-staging-prod a los workflows de IA.
Tres entornos
Cada workflow existe independientemente en tres entornos. Cada uno tiene su propia configuración, sus propios requisitos de aprobación y su propio historial de despliegue.
| Entorno | Aprobación Requerida | Rol Mínimo de Promoción |
|---|---|---|
| Development | No | Member |
| Staging | Sí | Dept Lead |
| Production | Sí | Admin |
Development es la caja de arena. Cualquiera del equipo puede desplegar aquí sin aprobación. Pruebe nuevos prompts, cambie modelos, agregue pasos — itere libremente sin riesgo.
Staging refleja producción pero con límites seguros. La promoción de dev a staging requiere que un Dept Lead revise y apruebe los cambios. Aquí es donde valida que un workflow se comporta correctamente antes de que maneje cargas de trabajo reales.
Production es el entorno en vivo. La promoción de staging a producción requiere aprobación de Admin. Los cambios aquí afectan usuarios reales, datos reales, outputs reales.
Configuraciones independientes por entorno
Los entornos no son solo niveles de permisos. Cada uno lleva su propia configuración operativa:
- Instancias de servidor MCP — Slack sandbox en dev, Slack de producción en prod. Pruebe contra integraciones mock sin disparar efectos secundarios reales.
- Proveedor y modelo LLM predeterminado — Use un modelo más barato y rápido en dev para iteración rápida. Use el mejor modelo en prod para calidad de output.
- Puertas de aprobación — Diferentes requisitos de rol por entorno, coincidiendo con la tolerancia al riesgo de su organización en cada nivel.
- Webhooks de despliegue — Notifique a diferentes canales de Slack o sistemas CI/CD por entorno. Los despliegues de dev notifican a
#eng-dev, los despliegues de producción notifican a#ops-alerts. - Variables de entorno — Pares clave-valor no secretos inyectados en plantillas de pasos. Apunte
API_BASE_URLa su servidor de prueba en staging y su servidor de producción en prod.
Esta separación significa que un workflow en desarrollo puede llamar a una API sandbox, usar un modelo más barato y omitir llamadas a herramientas costosas — mientras que el mismo workflow en producción usa integraciones reales, el mejor modelo y procesamiento completo.
El pipeline de promoción
La promoción sigue una secuencia estricta. Sin atajos.
- Un desarrollador hace cambios y despliega a dev. No se necesita aprobación — despliegue tantas veces como quiera.
- El desarrollador solicita promoción de dev a staging. El sistema calcula un diff de versión — una comparación estructural de qué cambió entre la versión actual de staging y la versión propuesta.
- Un Dept Lead revisa el diff y aprueba o rechaza la promoción.
- Al aprobar, la versión del workflow se auto-despliega a staging. Esto es atómico — la aprobación y el despliegue ocurren en un solo paso. No hay ventana donde una promoción está aprobada pero aún no desplegada.
- El mismo proceso se repite de staging a producción, requiriendo aprobación de Admin.
Prevención de auto-aprobación: la persona que solicita una promoción no puede aprobarla. Esto obliga a un segundo par de ojos en cada cambio que se mueve hacia producción.
Motor de diff de versión
Los revisores no aprueban a ciegas. Ven exactamente qué cambió.
El motor de diff coincide pasos por ID entre versiones y compara más de 15 propiedades:
- Tipo de paso, etiqueta, modelo y proveedor
- Asignación de recipe y descripción de tarea
- Contenido del prompt del sistema
- Lógica de condición (configuración if/then/else)
- Configuración de bucle (límites de iteración, condiciones de ruptura)
- Criterios de evaluación y umbrales de calidad
- Dependencias de pasos
- Pasos anidados dentro de condicionales y bucles
Los cambios se renderizan como descripciones legibles por humanos:
- “Modelo cambiado de ‘claude-sonnet’ a ‘claude-opus’”
- “Umbral de calidad cambiado de 0.7 a 0.9”
- “Prompt del sistema modificado”
- “Paso ‘Resumir’ agregado”
- “Iteraciones máximas del bucle cambiadas de 3 a 5”
El diff también detecta cambios en esquemas de entrada/salida (campos agregados, eliminados o modificados) y cambios en el modo de ejecución (secuencial vs. DAG). Un revisor ve el panorama completo: qué pasos cambiaron, cómo cambiaron y qué cambios estructurales ocurrieron en el workflow en su conjunto.
Rastreo de despliegues
Cada despliegue crea un registro:
- Estado —
active,supersededorolled_back - Desplegador — Quién activó el despliegue
- Info de aprobación — Quién aprobó la promoción, cuándo, y el solicitante original
- Resumen de diff — Qué cambió en este despliegue comparado con el anterior
- Marca de tiempo — Cuándo el despliegue entró en vivo
El historial de despliegue es consultable por workflow, por entorno. Puede rastrear el ciclo de vida completo de cualquier workflow en cualquier entorno: qué se desplegó, cuándo, por quién, y qué cambió cada vez.
Rollback
Un clic. Instantáneo.
El rollback no re-ejecuta nada. Cambia los estados de despliegue: el despliegue active actual se marca como rolled_back, y el despliegue superseded anterior se convierte en active de nuevo.
Esto es un cambio de estado, no un redespliegue. La versión anterior ya está ahí — solo necesita ser reactivada. Sin paso de compilación, sin pipeline de promoción, sin esperar aprobación. Cuando la producción se rompe, lo arregla en segundos, luego investiga la causa raíz con tiempo a su favor.
Registro de auditoría
Cada operación se registra:
- Cambios de configuración en ajustes de entorno
- Despliegues a cualquier entorno
- Solicitudes de promoción (quién solicitó, desde qué entorno, hacia cuál)
- Aprobaciones, rechazos y cancelaciones de promoción
- Operaciones de rollback
Cada entrada de registro incluye instantáneas completas antes/después. Puede reconstruir el estado exacto de cualquier entorno en cualquier momento. Esto no es solo higiene operativa — es un requisito de cumplimiento para organizaciones en industrias reguladas.
Integración con agentes VPC
Para organizaciones que ejecutan despliegues híbridos, los agentes de ejecución VPC pueden tener alcance a entornos específicos.
Un agente de producción solo maneja ejecuciones de workflow de producción. Un agente de dev solo maneja ejecuciones de desarrollo. Esto proporciona aislamiento de datos a nivel de infraestructura — los experimentos de desarrollo nunca tocan recursos de cómputo de producción, y los datos de producción nunca fluyen a través de infraestructura de desarrollo.
Combinado con servidores MCP específicos por entorno y variables de entorno, esto crea aislamiento completo desde la capa de integración hasta la capa de ejecución.
Disponibilidad
La gestión de entornos está disponible en los planes Enterprise. Incluye pipelines de promoción de tres entornos, diff de versiones, puertas de aprobación, rastreo de despliegues, rollback y registros de auditoría. Conozca más sobre funciones enterprise o inicie su prueba gratuita.