Portfolioこの記事について
本番環境とテスト環境で同期動作を分けたい場合や、一時的に同期を停止したい場合があります。そのため、環境変数で同期のON/OFFを制御できる設計にしました。
なぜ同期制御が必要なのか
制御が必要になるシーン
制御がないと起きる問題
- テスト時に本番POSにゴミデータが登録される
- POS障害時に全ての登録が失敗する
- 部分的な機能リリースができない
環境変数による制御の設計
基本的な考え方
環境ごとの設定例
処理フローへの組み込み
条件分岐の考え方
同期処理の条件分岐
顧客登録リクエスト受付
フォームから送信されたデータを受け取る
Shopify登録（常に実行）
顧客マスターとして最優先で登録
ENABLE_POS_SYNC チェック
ON → POS同期を実行 / OFF → スキップ（ログ記録）
ENABLE_CRM_SYNC チェック
ON → CRM同期を実行 / OFF → スキップ（ログ記録）
登録完了
結果を顧客に返却
スキップ時のログ記録
同期をスキップした場合でも、後から追跡できるようにログを残します。
後で「なぜPOSに同期されていないのか」を追跡可能です。
運用シナリオ
シナリオ1: 段階的なリリース
フェーズ1: Shopifyのみ
POS同期OFF、CRM同期OFFで本番リリース。まず基本機能を検証
フェーズ2: POS追加
POS同期ONに変更。Shopify登録済みの顧客を一括でPOSに同期
フェーズ3: CRM追加
CRM同期ONに変更。マーケティング連携を開始
シナリオ2: 障害時の切り離し
POS障害発生時の対応
通常時
POS同期: ON、CRM同期: ON、すべて正常に動作
障害対応中
POS同期: OFFに変更（即座に切り替え）、CRM同期: ON（影響なし）、顧客登録は継続可能
復旧後
POS同期: ONに戻す、障害中の登録を一括同期、通常運用に復帰
シナリオ3: テスト環境での制御
設計上の注意点
フラグ確認のタイミング
デフォルト値の設計
この設計がもたらす効果
開発チームにとって
- テスト時に本番システムを汚さない
- 段階的なリリースが可能
- 障害時の影響を最小化できる
運用チームにとって
- 障害時に迅速な対応が可能
- メンテナンス時の制御が容易
- 設定変更がデプロイなしで可能
ビジネスにとって
- サービス停止時間の最小化
- リスクを抑えた機能追加
- 柔軟な運用体制の実現