開発中の機能
コード管理
トラブルシューティング

トラブルシューティング

コード管理の運用中によく発生する困りごとと、その対処方法をまとめます。

本ページでは「現状の対応方法」と並べて、今後追加予定の機能bm rollbackbm hotfixdraftActions)を使った将来の対応方法も紹介します。将来の対応方法は構想段階のため、仕様は変更される可能性があります。

各ケースごとに、該当する「現状の対応方法」「将来の対応方法」またはその両方を記載します。

バージョンを戻したい

1つのアクションを以前のバージョンに戻したい

状況: 本番環境にデプロイした特定のアクションに不具合があり、そのアクションだけを以前のバージョンに戻したい。

対応方法

アクション単位のバージョン巻き戻しはWeb UIからのみ行なえます(CLIには該当コマンドがありません)。

  1. 本番環境のアクション一覧から、対象のアクションのバージョン/有効化設定画面を開く
  2. 戻したい特定のバージョンを選択して保存する

今後追加予定のbm rollbackはデプロイ単位の巻き戻しのみを扱います。アクション単位の巻き戻しは、将来も引き続きWeb UIから行なう想定です。

注意事項

  • バージョンを戻しても、設定ファイル(basemachina.config.ts)の内容は変わりません。次回のbm sync <環境ID>で設定ファイルの内容が再度反映されるため、根本対応として設定ファイルも修正する必要があります

直前のデプロイ全体を取り消したい

状況: 本番環境へのbm sync <環境ID>で複数のアクションをまとめてデプロイしたが、デプロイ全体を取り消したい。

現状の対応方法

現状は、Web UIから1アクションずつ手作業でバージョンを戻す方法しかありません。

  1. 本番環境のアクション一覧から、デプロイで更新された各アクションのバージョン/有効化設定画面を開く
  2. 戻したい特定のバージョンを選択して保存する
⚠️

bm sync <環境ID>同期元環境(開発環境または検証環境)の現在の状態を本番環境に反映するコマンドです。そのため、本番ブランチでgit revertしてCIを再実行しても、同期元環境のバージョンがすでに進んでいれば本番環境は戻りません。デプロイ後に開発環境での変更が続いている通常の運用では、git revertによる復旧はできません。

将来の対応方法

ロールバック(bm rollbackで、デプロイ単位の一括ロールバックを実行します。

環境ごとに異なるバージョンで動かしたい

状況: 開発環境では新しいバージョンで開発を続けつつ、本番環境だけは以前のバージョンに戻して動かしたい。

現状の対応方法

本番環境のWeb UIで対象のアクションを以前のバージョンに切り替えます。ただし、次回のbm sync <環境ID>で開発環境のバージョンが再度反映されてしまうため、本番デプロイのタイミングを制御する必要があります。

将来の対応方法

bm rollbackで本番環境のみを以前のデプロイ時点に戻すか、bm hotfixで本番環境専用のバージョンを作成します。

環境間でバージョンを揃え直したい

状況: 何らかの理由で検証環境と本番環境のバージョンがずれてしまったため、揃え直したい。

対応方法

bm syncで同期元の環境を明示的に指定して再同期します。

# 検証環境のバージョンを本番環境に揃える
bm sync <本番環境のID> --from <検証環境のID>

詳細はbm syncの他の環境への同期を参照してください。

特定の環境だけ修正したい

本番環境でのみ緊急修正を入れたい

状況: 本番環境でのみ発生するバグが見つかり、開発環境を経由せずに本番環境だけを直接修正したい。

現状の対応方法

現状のbm syncでは、開発環境を経由しないと本番環境のアクションを修正できません。やむを得ずWeb UIでアクションを直接修正する場合は、新しいバージョンを作成したうえで、本番環境のバージョン/有効化設定画面から作成したバージョンを紐づけます。その後、変更内容を設定ファイルにも反映する必要があります。

将来の対応方法

bm hotfixコマンドで、本番環境のアクションを直接修正します。想定する運用フローは以下の通りです。

  1. 本番デプロイ用のブランチ(prdブランチなど)から、hotfix用のブランチを作成する
  2. hotfixブランチで設定ファイルを修正する
  3. PRを作成すると、CIでbm hotfix <本番環境のID> --dryが実行され、差分がPRにコメントされる
  4. PRをマージすると、CIでbm hotfix <本番環境のID>が実行され、本番環境に反映される

詳細はhotfix(bm hotfixを参照してください。

hotfixの内容を開発ブランチに取り込み忘れた

状況: bm hotfixで本番環境を直接修正したが、その内容をmainなどの開発ブランチに取り込み忘れた。

注意事項

hotfixの内容を開発ブランチに取り込まないと、次回の通常デプロイ(bm sync <本番環境のID>)でhotfix適用前の時点の開発環境のバージョンに上書きされ、hotfixの修正が失われます。

hotfixを当てた後は、必ず以下のいずれかを行なってください。

  • hotfixブランチを開発ブランチ(mainなど)にもマージする
  • hotfixで変更した内容と同等の修正を、開発ブランチに別途PRで取り込む

設定ファイルとWeb UIの整合性

Web UIで変更した内容をコード管理に戻したい

状況: Web UIから誤って変更してしまったアクションを、設定ファイルの内容に戻したい。

対応方法

設定ファイルを変更せずにbm syncを実行します。Web UIで変更されたアクションは、次回のbm syncで「コード管理に移行(設定変更あり)」として設定ファイルの内容に上書きされます。

詳細はbm syncの管理方法による挙動の違いを参照してください。

Web UIで変更した内容を設定ファイルに取り込みたい

状況: Web UIで意図的に変更した内容を、設定ファイルにも反映してコード管理に戻したい。

対応方法

現状、Web UIから設定ファイルへの自動的な書き戻しは提供されていません。以下のいずれかの方法を使って手動で取り込みます。

  • 環境設定画面の「全アクションの設定内容のダウンロード」から再ダウンロードし、変更されたアクションのファイルだけ差し替える
  • Web UIで変更内容を確認し、対応する設定ファイルを手動で更新する

更新後、bm sync --dryで差分が出ないことを確認してから運用に戻します。

設定ファイルから誤ってアクションを削除した

状況: 設定ファイルから誤ってアクションの定義を削除してしまいました。bm syncはまだ実行していない、または--with-disableを指定していません。

対応方法

設定ファイルからアクションを削除しただけでは、--with-disableを指定しない限り環境上のアクションは変更されません。git revertまたは手動で設定ファイルを元に戻し、再度bm syncを実行してください。

--with-disableを指定して開発環境で無効化してしまった場合も、設定ファイルにアクションを戻してbm syncを実行すれば、開発環境で自動的に再有効化されます。

詳細は開発環境での無効化と再有効化を参照してください。

設定ファイルから削除したアクションを環境からも削除したい

状況: 不要になったアクションを設定ファイルから削除したので、環境上でも無効化したい。

対応方法

--with-disableオプションを指定してbm syncを実行することで、開発環境上のアクションを無効化できます。

bm sync --with-disable

検証環境・本番環境への伝播は、その後のbm sync <環境ID>で行ないます。

--with-disableはアクションを削除するのではなく、有効化設定を「無効」に変更する操作です。アクションのデータと識別子(displayID)は保持されるため、設定ファイルに戻してbm syncを実行すれば再有効化できます。

デプロイ事故への対処

反映したくない変更が本番ブランチにマージされた

状況: レビューが不十分なPRや、まだリリースしたくない変更が、誤って本番デプロイ用のブランチにマージされてしまいました。

対応方法

現状は、本番環境のWeb UIから、マージ内容に含まれる各アクションを手作業で以前のバージョンに戻します。前述の「直前のデプロイ全体を取り消したい」と同じ手順です。

git revertでブランチの履歴を戻しても、同期元環境のバージョンがすでに進んでいれば本番環境は戻らないため、Web UIでの手作業が必要になります。

将来的には、bm rollbackによるデプロイ単位のロールバックでも対応できる予定です。

本番に反映したくないアクションを分離したい

状況: 開発中・実験中のアクションがbm sync <環境ID>で他の環境にも反映されてしまうのを防ぎたい。

現状の対応方法

アクションの有効化設定で、対象アクションを開発環境でのみ有効、他の環境では無効に設定します。

⚠️

環境ごとの有効/無効はコード管理の対象外です(defineActionの注記を参照)。設定ファイルでは指定できないため、Web UIの環境別の設定画面から個別に切り替えてください。

将来の対応方法

設定ファイルで、対象アクションをactionsではなくdraftActionsフィールドに移動します。draftActionsに入れたアクションはbm syncで開発環境にのみ反映され、bm sync <環境ID>の対象外となります。

詳細は開発環境限定のアクション(draftActionsを参照してください。

ビュー(コード取得設定)との組み合わせ

コード取得設定を使ってビューも同じリポジトリで管理している場合の対処方法です。

アクションのロールバックに合わせてビューも戻したい

状況: アクションを以前のバージョンに戻したが、ビュー(コード取得設定で読み込んでいるコード)が新しいままで動作しない。

対応方法

ビューはアクションのバージョン履歴とは独立して、ストレージ上のファイルとして管理されています。アクションのロールバックと合わせてビューも戻すには、本番デプロイ用のブランチ(prdブランチなど)でビューのコードを修正してマージしてください。

⚠️

通常のCI構成(2ブランチ運用3ブランチ運用の例)では、本番ブランチへのマージをトリガーにbm sync <環境ID>が自動実行されます。その結果、同期元環境の現在のバージョンが再度反映され、Web UIで戻したアクションが最新バージョンに戻ってしまいます

これを防ぐには、CIの設定に以下のような調整を加える必要があります。

  • アクションのbm sync <環境ID>は、検証環境ブランチからのマージ経由でのみ実行するようにし、本番ブランチ直接のpushでは走らせない
  • ビューのビルド・アップロードは、ビューのコードに変更があるときにだけ実行するようにする

これにより、本番ブランチでビューだけを修正してマージしても、アクションの再同期は走らずビューだけが差し戻されます。

hotfixと一緒にビューも修正したい

状況: bm hotfixでアクションを修正するとき、関連するビューのコードも一緒に修正したい。

このシナリオは、将来追加予定のbm hotfixを使った運用を想定したものです。現状はbm hotfixが存在しないため発生しません。

将来の対応方法

hotfixブランチでビューのコードも修正してから、PRをマージします。CI/CDでは以下の流れになります。

  1. hotfixブランチで設定ファイルとビューのコードを両方修正する
  2. PRをマージすると、CIでbm hotfix <本番環境のID>とビューのビルド・アップロードが実行される
  3. アクション、ビューの双方が同時に本番環境に反映される

hotfixの内容と同様に、ビューの修正内容も後から開発ブランチ(mainなど)に取り込み、次回の通常デプロイで上書きされないようにしてください。