Así que somos un equipo de desarrollo pequeño, con edición comunitaria auto-hospedada, construyendo flujos de trabajo de automatización para clientes. Nos hemos topado con algo bastante básico y estoy curioso de saber si otros lo han resuelto o si todos estamos improvisando.
Nuestro proceso actual es vergonzoso honestamente. Para mover algo de staging a prod exportamos el JSON, lo importamos en el otro servidor, y luego manualmente revisamos y arreglamos credenciales, URLs, variables de entorno, lo que sea que se haya roto en la transferencia. Con 10-12 flujos de trabajo en nuestro proyecto principal esto ya es molesto. El problema más grande es que no hay una manera limpia de dar a cada desarrollador su propio setup aislado para probar cambios sin estar copiando y pegando todo manualmente de un lado a otro, y nuestro servidor de staging termina siendo este desorden compartido donde todos nos pisamos los pies.
He buscado la característica de control de versiones pero eso solo está en business y enterprise y no estamos pagando €667/mes por eso.
¿Hay algún flujo de trabajo que la gente haya hecho funcionar realmente aquí? ¿O todos estamos viviendo con el caos del copiar y pegar?
Hola @PurveshGandhi
Para un cambio rápido entre entornos, exportar e importar el JSON del flujo de trabajo es la opción más simple.
Para algo más mantenible entre staging-prod, creo que los entornos de control de versiones de n8n son el mejor camino a largo plazo, porque los flujos de trabajo se versionan en ramas de Git.
Solo ten en cuenta que las credenciales y los valores de variables no se sincronizan automáticamente, así que todavía necesitan configurarse por instancia.
Entonces, exportar-importar para una copia rápida, control de versiones para el flujo de trabajo de entorno adecuado.
Dividiría esto en dos capas: forma del flujo de trabajo y vinculación del entorno.
Para Community Edition, no trataría el JSON exportado como todo el sistema de implementación. Mantén el JSON como la forma del flujo de trabajo, luego mantén un pequeño mapa de promoción junto a él:
- nombre del flujo de trabajo, propietario, disparador, sistemas anteriores, sistemas posteriores
- variables que cambian según entorno local, staging y producción
- stubs de credenciales por nombre y servicio, sin secretos en el JSON compartido
- una entrada de prueba de humo falsa o redactada por flujo de trabajo, más salidas esperadas
- lista de verificación de promoción: exportar, importar, vincular variables y credenciales, ejecutar fixture, activar, registrar notas de reversión
- regla de sandbox para desarrolladores: clon local o temporal solo con credenciales falsas; staging compartido debe ser la puerta de pre-producción, no la caja de experimentos
- Para 10-12 flujos de trabajo, una sola tabla de flujo de trabajo / credenciales / variables / prueba de humo / reversión generalmente mostrará qué flujos de trabajo son realmente difíciles de promover y cuáles solo necesitan nombres consistentes.
- Evitaría publicar exportaciones de credenciales reales. El siguiente fragmento seguro sería una lista sanitizada de los flujos de trabajo, nombres de credenciales anónimos, variables específicas del entorno y una transferencia que falló.
¡Bienvenido @PurveshGandhi a nuestra comunidad! Soy Jay y soy un creador verificado de n8n.
Un enfoque que puede ahorrarte el ciclo manual de exportación/importación en Community Edition es automatizarlo con la propia API REST de n8n. Puedes ejecutar un flujo de trabajo que llame a GET /api/v1/workflows en tu servidor de staging, extrae el JSON de cada flujo de trabajo, y luego POST /api/v1/workflows o PUT /api/v1/workflows/{id} en tu servidor de producción para sincronizarlo.
Para las credenciales, aún necesitas rebindearlas manualmente ya que los valores secretos no se exportan - pero puedes automatizar la sincronización de flujos de trabajo en sí. Combina esto con un mapa de variables de entorno almacenado en una Hoja de Google o un archivo JSON simple (nombre de credencial de staging → nombre de credencial de prod) y el paso de rebindeo se convierte en una sustitución de nodo Code antes del push, en lugar de una búsqueda manual.
Esto no te dará el branching/rollback del control de versiones, pero reemplaza el ciclo de copiar-pegar con un flujo de trabajo de un solo clic que se ejecuta en menos de 30 segundos para 10-12 flujos de trabajo.
¡Gracias @nguyenthieutoan! Esto es muy útil.
El sync basado en API tiene mucho sentido para la promoción de staging → prod. Dos seguimientos si no te importa:
Primero, también estamos construyendo para un par de proyectos de clientes junto con los nuestros, cada uno en instancias separadas de n8n. ¿Manejar múltiples flujos de sync y mapeos de credenciales por cliente se vuelve complicado, o se mantiene limpio?
Segundo, y este nos ha molestado más que el problema de la promoción honestamente. Mencionamos en el post original que nuestro servidor de staging es un desorden compartido donde los desarrolladores se pisan mutuamente. Tu enfoque de sync resuelve el push a prod, pero ¿qué haces para dar a cada desarrollador un entorno aislado para probar cambios sin contaminar staging? Esa es la parte que no hemos podido resolver.