アプリのステージング環境を構築する方法

ステージング環境を構築するには、アプリの2つ目のコピーを専用の非公開URLにデプロイし、専用のデータベースとテスト用APIキーを割り当て、本番の構成にできるだけ近づけます。そのうえで、重要な変更はすべてまずステージングにリリースし、主要な操作フローを確認し、ステージングで問題がなさそうだと確認できてから初めて本番に公開してください。

この考え方に馴染みがない場合は、ステージング環境とはで概念を説明しています。このガイドは、DevOpsチームを運用していない、AIツールでアプリを作っている人向けの実践的な構築手順です。

開発、ステージング、本番

最初の環境がビルダーのプレビューだけであっても、多くの小規模アプリには3つの環境が必要です。

ステージングの目的は、本番と同じように動くこと（同じコード、同じスタック、同じ種類の設定）です。そのうえで、そこで起きたミスは誰にも影響しません。

ステップ1：ステージングが何と一致している必要があるかを決める

ステージングは、本番で問題が起きる前にそこで問題が見つかって初めて役に立ちます。次の点を揃えてください。

• 同じコードを、同じ方法でリリースすること。
• 同じスタックとバージョン：フレームワーク、ランタイム、データベースの種類。
• 同じ種類の設定：同じ環境変数名を使い、値だけテスト用にすること。
• 同じサービス：本番にWebアプリとAPIがあるなら、ステージングにも両方あること。

規模（小さめのマシンで構わない）やデータは異なっていても問題ありません。

ステップ2：コピーを作る

最も簡単な方法は、同じプロジェクトの2つ目のデプロイを、staging.yourapp.com や yourapp-staging.example.com のような別のURLで行うことです。

方法はホストによって異なります。

• プレビューやステージング用のデプロイを標準で備えているホストは、Gitのブランチごとに自動で作成できます。
• 備えていないホストでは、同じコードから2つ目のアプリまたはプロジェクトを作り、個別にデプロイしてください。
• Gitでコードを管理している場合は、ステージングにデプロイする staging ブランチ（または main）を用意し、本番へはリリースからデプロイしてください。AIで作ったアプリでGitを使う方法を参照してください。

ステップ3：ステージング専用のデータベースを用意する

これは、あなたを守ってくれる重要なステップです。ステージングと本番がデータベースを共有していると、レコードを削除するテストが本物のレコードを削除してしまいます。

• ステージング用に別のデータベースを作成する。
• シードデータ（AIが生成できる、現実的な架空のレコード）で埋める。
• 本番データのコピーが必要な場合は、まず名前、メールアドレス、その他の個人情報を削除するか匿名化する。

空のデータベースに現実的なテストデータを投入するシードスクリプトを書いてください。顧客20件、さまざまな状態の注文50件、管理者ユーザー2名。名前は明らかに架空のものにし、メールアドレスは example.com を使ってください。

この設定を信頼する前に、それぞれのコピーがどのデータベースに接続しているかを確認してください。次のように直接尋ねましょう。

このアプリはどのデータベースに接続していますか？その設定はどこから来ていますか？パスワードではなく、変数名を示してください。

ステップ4：テスト用のキーと個別の設定を使う

外部サービスと通信するものは、すべてステージングでは テスト用 の認証情報を使ってください。

• 決済はテストモードで（たとえばStripeのテスト用キー）。実際のカードには請求されないようにします。
• メールはサンドボックスに送るか、自分のアドレスにだけ送ります。顧客にテストメッセージが届くことは絶対にないようにします。
• AIやその他の有料APIは別のキーを使い、低い利用上限を設定します。
• WebhookはステージングのURLに向け、本番には向けないでください。

両方の環境で、変数の 名前 は同じにし、値だけを変えてください。そうすれば、コードは自分がどの環境で動いているかを知る必要がありません。この点について詳しくは、APIキーを安全に管理する方法を参照してください。

ステップ5：ステージングを非公開に保つ

ステージングは公開すべきではありません。

• ログイン、パスワード、またはチームメンバーのメールアドレスの許可リストの背後に置く。
• noindex のmetaタグまたは X-Robots-Tag ヘッダーで、検索エンジンにインデックスさせないようにする。
• 公開サイトからリンクしない。
• 見た目を本番と変えておく。色付きの「STAGING」バナーを表示すれば、間違ったタブでテストしてしまうのを防げます。

APP_ENV 環境変数が "staging" の場合、すべてのページの上部に、明るい黄色のバナーで「STAGING — テストデータのみ」と表示してください。その場合は noindex のmetaタグも追加してください。

ステップ6：リリースの手順を決める

ステージングは、毎回使ってこそ役立ちます。シンプルな手順は次のとおりです。

1. 開発環境で変更を加え、プレビューで確認する。
2. ステージングにリリースする。
3. 主要な操作フローを確認する：登録、ログイン、主な機能、決済、今回の変更に関係したすべての箇所。
4. 問題が起きたら修正し、もう一度ステージングにリリースする。
5. 同じバージョンを本番に公開する。
6. 本番を素早く確認する。同じフローを短時間で確認します。

主要な操作フローは、短いテストスクリプトとして書き出しておいてください。何を含めるべきかは、公開前にアプリをテストする方法を参照してください。

ステップ7：データベースの変更は慎重に扱う

データベースの構造の変更（列の追加、テーブル名の変更など）こそ、ステージングの価値が発揮される場面です。

• 構造に関するすべての変更をまずステージングで実行する。
• 新機能が動くかだけでなく、既存のデータが無事かを確認する。
• 同じ変更を本番で実行する前に、本番のバックアップを取る。アプリのデータベースをバックアップする方法を参照してください。
• 名前変更や削除よりも、追加する変更を優先する。そうすれば、ロールバックした場合でも古いバージョンが動き続けます。

プロンプトの例

この database 変更を本番で実行すると、既存のデータにどのような影響があるか説明してください。何か削除されたり名前が変わったりしますか？

API のURL、キー、メールの送信元、サイト自身のURLなど、環境ごとに異なる設定はすべて、ステージングと本番で同じ名前の環境変数から読み込むようにしてください。その一覧を出してください。

このアプリの機能に基づいて、リリースのたびにステージングで確認すべきフローの簡単なチェックリストを書いてください。

よくある失敗

• データベースの共有。 最もダメージの大きい失敗です。ステージングには必ず専用のデータベースを用意してください。
• ステージングで本番のキーを使う。 実際の請求や、実際の顧客への誤ったメールが発生します。
• ステージングが本番からずれる。 バージョンや設定が違うと、ステージングでは問題を検出できなくなります。
• 公開され、インデックスされているステージングサイト。 本物のサイトの隣に検索結果に表示されてしまいます。
• 「小さい」変更ならステージングを省略する。 小さな変更でも、何かは壊れます。
• 間違ったタブでテストする。 目立つバナーがあれば防げます。

チェックリスト

• ステージングは本番と同じコード、スタック、サービスで動いている。
• ステージングには、テストデータまたは匿名化されたデータを持つ専用のデータベースがある。
• 決済、メール、有料APIは、ステージングではテスト用キーを使っている。
• 環境間で変数名が一致し、異なるのは値だけ。
• ステージングはログインまたはパスワードの背後にあり、インデックスされていない。
• ステージングにいるときはバナーが表示される。
• すべてのリリースはまずステージングに行き、確認すべきフローを書いたリストがある。
• データベースの変更はまずステージングで実行され、リリース前に本番のバックアップがある。

Mythexでのステージング

MythexのPublish機能では、アプリごとに公開URLが1つ用意されます。別のステージング切り替えはありません。実際には次の2つの方法があります。

• リリース前のチェックとしてプレビューを使う。 すべてのプロジェクトは、非公開のクラウドワークスペース上でライブのプレビューとともに動きます。/test を使うと、エージェントがユーザーのようにプレビューを操作します。また Share リンクを使えば、公開せずにクライアントやチームメイトがプレビューをレビューできます。詳しくはプレビューとコードを参照してください。個人で作る多くのプロジェクトではこれで十分です。
• 2つ目のプロジェクトをステージングとして使う。 Proプランでは、プロジェクトをエクスポートし、新しいプロジェクトとしてインポートします。その新しいプロジェクトには専用のデータベースとテスト用キーのシークレットを設定し、独自のスラッグで公開します。本番プロジェクトを公開する前に、そちらにリリースしてください。

どちらの方法でも、破壊的な操作をテストする前に、プレビューと公開済みアプリがどのデータベースを使っているかをエージェントに確認してください。また、問題のある変更をロールバックするにはチェックポイントを使ってください。アプリを広く本番で公開する方法については、AIプロトタイプを本番環境に持っていく方法を参照してください。

よくある質問