経緯
ある現場にて、セルフホスティングしたDifyを使ってLLMを利用したワークフローを構築、本番環境として運用するWebアプリケーションからAPI経由で呼び出し、連携しています。
このワークフローは全体としてはこんな感じで、さらに部分部分で別の子ワークフローを呼び出しているという、まぁまぁ巨大なものになっています。
このワークフローを複数のエンジニアで手分けしつつ編集したい状況が生まれました。
懸念事項
テスト環境のDifyサーバーと本番環境のDifyサーバーはそれぞれ別々に立てており、基本的に本番環境ではなくテスト環境でワークフローを編集、本番環境には同じ修正内容を適用のみ行う運用にしたいところです。これをいかに安全に行うか課題となります。
また、そこを乗り越えたとして、テスト環境でワークフローを編集をするときにも以下のような懸念があります。
- 間違った編集をしたときどうするか
- 複数人が同時編集したら排他制御どうなるのか (誰かの編集以外の情報が裏宇宙に消えないか)
特に同時編集については実際手もとの変更が消えたこともあり、安全を期すために以下のような運用手順に至りました。
実際の運用手順
1. DSL をエクスポートしてgitで管理
Difyには、アプリケーション自体にバージョン管理の仕組みが内包されています。
作業中のうっかりミスをもとに戻す、というくらいならいいですが、本番環境に反映する断面を適切にコントロールするということも考えると、やはりバージョンコントロールの仕組みを利用したいところです。
Difyでは設定内容をDSLでダウンロード可能なのでこれを利用します。
テスト環境でDifyのDSL(YAML形式)をエクスポート、gitにてコミットして管理しておきます。
親だけでなく、そこから呼び出される子ワークフロー含め、実際に利用するすべてのワークフローを対象にバージョン管理を行います。
2. 作業者はmainブランチ相当のワークフローを複製して編集
テスト環境にて、mainブランチ相当のワークフローを複製してtopicブランチ相当のものを作成、そちらで作業を行いテストします。
3. OKならmainブランチ相当のワークフローに取り込むためにSlack上で悲観ロック(物理)を取得
そこまで作業してOKならmainブランチ相当のワークフローに取り込みますが、ここで複数人が一緒に作業して思わぬ状態になることを防ぐため念の為Slackで編集を宣言し、他のエンジニアの作業をブロックします。
4. 手作業で同じ内容をmainブランチ相当のワークフローに反映してテスト、OKならDSLコミット
手作業でtopicブランチ相当のワークフローで行った変更をmainブランチ相当のワークフローへ反映します。
無事に終ればmainブランチ相当のワークフローにてDSLをダウンロード、gitにコミットします。
5. 悲観ロック(物理)解放
ロックも解放しましょう。
7. 本番環境にDSLインポート
最後に本番環境に反映します。
もし問題があればgit管理されたDSLを再度テスト環境のmainブランチ相当のワークフローにimportして復元可能です。
感想
同時編集する可能性があるといっても2〜4人くらいですが、ひとまずこれでいい感じに回っていました。
チームによってはテスト環境を使うときにSlackで宣言して他のメンバーに知らせるといったことを行っていますが、それと同じ。