J’ai plusieurs workflows n8n en production, et je commence à les modifier plus fréquemment.
Le problème, c’est qu’une petite modification de workflow peut parfois affecter les exécutions existantes, les requêtes de base de données ou les intégrations API. Je ne veux pas tester les modifications directement en production et découvrir le problème après que les clients en soient déjà affectés.
Ma configuration actuelle est à peu près :
Développement
↓
Test
↓
Production
J’envisage de conserver les versions de workflows dans Git et d’utiliser des migrations de base de données pour tout changement de schéma.
Par exemple :
ALTER TABLE orders
ADD COLUMN processing_version INTEGER DEFAULT 1;
Mais je ne suis pas sûr de la façon dont les autres gèrent les modifications lorsque d’anciennes exécutions sont encore en cours.
Vous-même, vous :
Versionneriez les workflows et les déploieriez progressivement ?
Garderiez les anciennes et nouvelles versions de workflows en cours d’exécution temporairement ensemble ?
Utiliseriez des migrations de base de données rétrocompatibles ?
Réinitialiseriez automatiquement un workflow si le taux d’erreurs augmente ?
Sépareriez le déploiement du workflow du déploiement du schéma de base de données ?
À quoi ressemble un processus de déploiement n8n fiable quand on a plusieurs workflows de production et plusieurs workers fonctionnant continuellement ?
Décrivez le problème/l’erreur/la question
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre workflow
(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)
Salut @Selena_Gloria, je traiterais les modifications de flux de travail n8n comme des déploiements d’applications plutôt que d’éditer directement les flux de production.
Mon approche serait :
Développement
↓
Test
↓
Versionnage / Sauvegarde
↓
Déploiement
↓
Surveillance
↓
Rollback si nécessaire
Pour les modifications de base de données, je rendrais d’abord les migrations rétrocompatibles. Par exemple, ajouter une nouvelle colonne avant de déployer un flux de travail qui en dépend :
ALTER TABLE orders
ADD COLUMN processing_version INTEGER;
Ensuite, déploie la modification du flux de travail. Une fois que les anciennes exécutions sont terminées, tu peux supprimer ou modifier l’ancien schéma en toute sécurité.
Pour les changements plus importants, je supporterais temporairement les deux versions :
Ancien Flux de travail → Ancienne Logique
Nouveau Flux de travail → Nouvelle Logique
Cela rend le rollback beaucoup plus sûr car les exécutions existantes ne dépendent soudainement pas d’un schéma ou d’un champ qui n’existe plus.
Je surveillerais également les échecs d’exécution, les erreurs API, la profondeur de la file d’attente et la santé des workers immédiatement après le déploiement.
Salut @Selena_Gloria, les workers de file d’attente utilisent le workflow sauvegardé avec l’exécution, donc publier une modification ne remplace pas ses nœuds en cours d’exécution. Une exécution Wait en pause reprend également avec son workflow sauvegardé. La base de données et les API qu’il appelle peuvent toujours changer dessous.
Je recommande de promouvoir le même commit Git testé à travers vos environnements, en déployant d’abord les migrations de base de données additives. Gardez l’ancien schéma compatible jusqu’à ce que les exécutions AND en attente soient terminées, plus votre fenêtre de rollback. Gardez les mises à niveau de version n8n séparées des versions de workflow.
Pour un déploiement progressif, conservez un workflow d’entrée unique et routez vers des sous-workflows v1/v2 séparés à l’aide d’un nœud Switch. Votre colonne processing_version peut stocker ce choix quand une commande entre en traitement, donc les nouvelles tentatives utilisent la même version. N’activez pas deux déclencheurs indépendants qui traitent tous les deux le même événement.
Commencez avec un petit groupe de nouvelles commandes sur v2. Si les erreurs augmentent, arrêtez d’assigner de nouvelles commandes à v2 et enquêtez sur celles déjà lancées. Le passage en arrière ne défait pas les paiements, les e-mails ou les écritures de base de données, donc ces étapes ont toujours besoin d’une protection contre les doublons.
J’ai traversé exactement ça avec des workflows qui ont de vrais clients à l’autre bout, donc voici ce qui a réellement survécu au contact avec la production pour moi.
Je garde chaque workflow de production dans Git avec un schéma numéroté en accompagnement (ton instinct sur la colonne processing_version est juste). La règle qui a rendu les anciennes exécutions sûres : une nouvelle version de workflow doit pouvoir lire les lignes écrites par les deux dernières versions. Les anciennes exécutions se terminent avec le code avec lequel elles ont commencé, les nouvelles reprennent la nouvelle logique, et rien ne mute en vol.
Avant que tout changement ne passe en production, j’exécute l’ancienne et la nouvelle ensemble pendant un cycle complet - pas indéfiniment, juste le plus long intervalle planifié que j’ai. La nouvelle version écrit dans une destination shadow (table de staging ou file d’attente étiquetée) tandis que l’ancienne continue à faire le vrai travail, ensuite je compare les résultats. Quand ils correspondent pendant un cycle complet, je bascule la destination et je retire l’ancienne. C’est ce qui détecte les surprises d’intégration API que les tests unitaires ne trouvent jamais.
Les modifications de schéma vont dans un seul sens : ajoute des colonnes nullable, remplis par lots, ne renomme jamais sur place. Ton ALTER TABLE ADD COLUMN DEFAULT 1 est exactement la forme sûre - les suppressions et changements de type sont les dangereux, et ceux-là attendent qu’aucune version en cours de fonctionnement ne les référence.
Dernière habitude : contrôle le déclencheur, pas le workflow. Désactive le déclencheur pendant une limite d’intervalle, laisse les exécutions en file d’attente s’écouler, déploie, réactive. Une discipline bon marché qui prévient le jour « petit changement a redémarré 400 exécutions en file d’attente ».
La colonne vertébrale Git + migrations que tu as déjà est juste - la période d’exécution shadow est le morceau qui la rend véritablement sûre.