n8nの変更を本番へ渡す際は、workflowの版、接続先、公開状態、戻す版をまとめて確認します。試験で使ったCredentialsや送信先が、そのまま本番のJSONへ残っていないかも点検が必要です。
変更した版と、いま動いている版を記録する
ファイル名だけで管理すると、同じ名前のworkflowが複数環境にある場合に取り違えます。環境名、workflow ID、書き出した版の識別、変更した処理を記録します。
反映の記入票
試験環境のworkflow ID：
本番のworkflow ID：
変更する版：
主な変更：
使うCredentialsと送信先：
公開する時刻：
戻す版と担当：Credentialsの名前が同じでも接続先が同じとは限りません。環境ごとの参照と、実際に許される操作を照合します。
試験用の入力・URL・固定データを外す
Data pinningは開発時の確認に使える機能です。本番実行では同じ固定入力になるとは限らないため、実際のトリガーから届くデータを別に試します。対応範囲は公式Data pinningで確認できます。
Webhook URL、担当者の通知先、試験シート、モックの外部応答を一覧で確認します。書き出したworkflowにはURLや設定値が残る場合があるので、秘密を含むファイルをGitへ公開しないようにします。
反映前の試験を、変更内容へ対応させる
| 変更 | 確認する試験 |
|---|---|
| 分類条件 | 正常・未分類・境界の入力 |
| 接続先や認証 | 対象の照合、権限不足、失効 |
| 外部登録 | 再送、途中停止、結果IDの照合 |
| 定期実行 | 公開状態、時刻、起動と完了の記録 |
反映した後は、workflowの保存だけで終えず、本番で一件がどこまで進んだかを確認します。件数が多い仕事は、少数から始めて記録を読んでから増やします。
戻す際は、workflowと外部結果を別に扱う
以前のworkflowへ戻しても、すでに送信したメールや作成した投稿は自動で戻りません。実行中の処理、完了済みID、外部の変更を確認してから、どこから再開するかを決めます。
まず一つの変更について、試験結果と戻す版を一緒に保存してください。試験の項目はworkflowのテストへ、再開の重複確認は二重実行の防止へ分担します。