Los ingenieros de software no despliegan código sin control de versiones. Revisan diffs, prueban en staging y hacen rollback cuando algo se rompe. Los flujos de trabajo de IA merecen la misma disciplina.
El sistema de control de versiones de flujos de trabajo de JieGou le da historial de versiones inmutable, diffing estructural, rollback con un clic y despliegues canary — todo integrado en el editor de flujos de trabajo.
Cada edición crea una versión
Cuando modifica la estructura de un flujo de trabajo — agregando, eliminando o reordenando pasos, cambiando esquemas de entrada/salida — JieGou automáticamente crea una nueva versión. El historial es solo de adición. Nada se sobrescribe.
Cada versión es una instantánea completa: cada paso, cada mapeo de entrada, cada definición de esquema, congelado en el tiempo. Puede navegar la cronología completa de la evolución de un flujo de trabajo, ver quién hizo cada cambio y cuándo, y entender exactamente cómo un flujo de trabajo llegó a su estado actual.
Esto sucede de forma transparente. Usted edita flujos de trabajo de la misma manera que siempre lo ha hecho — la capa de versionado funciona detrás de escena.
Diffing estructural
Saber que algo cambió no es suficiente. Necesita saber qué cambió.
El motor de diff compara dos versiones cualesquiera estructuralmente. Identifica:
- Pasos agregados — Nuevos pasos que no existían en la versión anterior
- Pasos eliminados — Pasos que fueron borrados
- Pasos modificados — Pasos donde la configuración cambió (receta, mapeos de entrada, condiciones, configuración de bucle, política de aprobación)
- Pasos reordenados — Pasos que cambiaron de posición en el orden de ejecución
- Cambios de esquema — Campos agregados, eliminados o modificados en esquemas de entrada/salida
Para pasos modificados, el diff va más profundo. Estructuras anidadas como ramas condicionales (thenSteps / elseSteps), cuerpos de bucle y ramas paralelas se comparan recursivamente. Ve exactamente qué campo en qué paso cambió.
El resultado es un resumen legible por humanos — “2 paso(s) modificados, 1 paso(s) agregado, esquema de entrada cambió” — junto con la vista detallada del diff.
Rollback como nueva versión
El rollback no reescribe el historial. Cuando hace rollback a la versión 3, JieGou copia los pasos y esquemas de esa versión en una versión completamente nueva (digamos, versión 8). La cronología muestra la historia completa: las versiones 4 a 7 existieron, algo salió mal, y la versión 8 es una restauración de la versión 3.
Esto significa que los rollbacks son seguros. Siempre puede avanzar de nuevo si el rollback mismo fue un error.
Rollouts canary
El momento más riesgoso para cualquier flujo de trabajo es justo después de un cambio. Los rollouts canary le permiten probar cambios en una fracción del tráfico automatizado antes de comprometerse.
Así es como funciona:
- Iniciar un canary. Seleccione la nueva versión y un porcentaje de tráfico — digamos, 10%.
- Enrutamiento automatizado. Cuando una programación o webhook dispara el flujo de trabajo,
resolveWorkflowVersion()genera un número aleatorio. 10% de las ejecuciones se enrutan a la versión canary; 90% continúan con la versión activa. - Las métricas se acumulan. Cada ejecución registra éxito/fallo, duración y uso de tokens contra su versión. Los contadores Redis agregan estos en tiempo real.
- Promover o hacer rollback. Cuando tenga confianza, promueva el canary a activo (retirando la versión antigua). O haga rollback si las métricas no se ven bien.
Para operación sin intervención, configure auto-promoción: establezca un número mínimo de ejecuciones y una tasa mínima de éxito. Una vez que el canary alcanza ambos umbrales, se promueve automáticamente. Si el canary no ha alcanzado el umbral después de un límite de tiempo configurable, se hace rollback automáticamente.
La ejecución manual siempre usa la versión activa a menos que seleccione explícitamente una diferente.
Métricas por versión
Cada versión acumula sus propios datos de rendimiento:
- Total de ejecuciones — Cuántas veces se ha ejecutado esta versión
- Tasa de éxito — Porcentaje de ejecuciones que completaron sin error
- Duración promedio — Cuánto toma la ejecución en esta versión
- Conteo de errores — Cuántas ejecuciones fallaron
Estas métricas potencian las decisiones de promover/rollback del canary, pero también son útiles para detectar regresiones. Si la versión 5 tenía una tasa de éxito del 98% y la versión 6 cae al 91%, sabe que algo cambió — y puede hacer diff de las dos versiones para encontrar qué.
Por qué esto importa
Sin control de versiones, los cambios de flujos de trabajo son irreversibles. Una mala edición significa reconstruir manualmente cómo se veía el flujo de trabajo antes. Con control de versiones:
- Los auditores pueden rastrear exactamente qué cambió, cuándo y por quién
- Los equipos pueden revisar diffs antes de promover cambios a producción
- Los operadores pueden hacer pruebas canary de cambios en tráfico real sin riesgo
- Cualquiera puede hacer rollback instantáneamente cuando algo se rompe
El historial de versiones y el diffing están disponibles en todos los planes. Los rollouts canary y la auto-promoción están disponibles en Enterprise. Conozca más sobre los flujos de trabajo o inicie su prueba gratuita.