最終更新日 2022年03月09日(水)

レビューアプリは、廃棄可能な Heroku アプリで、いずれかの GitHub プルリクエストのコードを実行します。共有可能で一意の URL を個々に備えるレビューアプリは、コードベースへの変更を提案、テスト、およびマージするための優れた手段です。

レビューアプリは、プルリクエストごとに自動的に起動するように設定することも、Heroku Dashboard でアプリの 「Pipeline」 (パイプライン) ページから手動で作成することもできます。

セットアップ

Enable Review Apps​ (レビューアプリの有効化) をクリックして、Heroku Dashboard​ にあるアプリのパイプラインページからレビューアプリを有効化にします。

GitHub リポジトリのマスターブランチで、必要な app.json​ ファイルがルートディレクトリに含まれていない場合は、次のダイアログが表示されます。

パイプライン内の “親” アプリで、正しい GitHub リポジトリに接続されているものを選択して Create an app.json File​ (app.json ファイルの作成) をクリックします。

これにより、app.json​ ファイルの初期バージョンに入力するために役立つフォームが開きます。フォームでどのような値を指定するかわからない場合は、Commit to Repo​ (リポジトリにコミット) をクリックすると、後から入力できるスケルトンの app.json​ ファイルをコミットできます。

Commit to Repo​ (リポジトリにコミット) をクリックした後 (またはアプリにすでに app.json​ ファイルが含まれていた場合)、次のダイアログが表示されます。

ここでは、以下を指定できます。

• レビューアプリでその設定の継承元にするアプリ
• 新しいプルリクエストに対してレビューアプリが自動的にスピンアップするかどうか
• 一定期間非アクティブの場合に古くなったレビューアプリを削除するかどうか

Enable​ (有効) をクリックしてセットアップを完了します。

レビューアプリの作成

レビューアプリを作成すると、関連付けられたプルリクエストのベースになっているブランチの HEAD​ コミットが Heroku によってデプロイされます。ブランチが更新されるたびに、Heroku によって最新のコミットがレビューアプリにデプロイされます。プルリクエストを閉じると、Heroku によってレビューアプリが破棄されます。

手動作成

アプリの 「Pipeline」 (パイプライン) ページには、接続中の GitHub リポジトリのプルリクエストでオープン状態のものが表示されます。リスト内のプルリクエストの横にある Create​ (作成) ボタンをクリックすると、そのリクエストに対してレビューアプリを手動で作成できます。

自動作成

自動作成では、アプリが接続している GitHub リポジトリでプルリクエストがオープンされるとすぐ、Heroku によってレビューアプリが作成されます。セキュリティおよび請求上の理由から、Heroku では、パブリックリポジトリへのプルリクエストのうちフォークから送信されたものに対しては、レビューアプリを自動的に作成しません​。なお、これらのプルリクエストに対してはレビューアプリを手動で作成できます。

レビューアプリの表示

レビューアプリが作成されると、ブラウザで開くためのリンクが GitHub から (プルリクエストの Conversation​ (会話) タブで) 利用可能になります。

このリンクは、Heroku Dashboard (アプリの 「Pipeline」 (パイプライン) ページの 「Review Apps」 (レビューアプリ) 列) でも利用できます。

​

他の Heroku アプリと同じように、レビューアプリの表示、管理、および検査ができます。View initial app setup​ (アプリの初期設定を表示) および View latest build​ (最新ビルドを表示) リンクをクリックすると、レビューアプリのデプロイステータスの詳細を表示できます。

app.json ファイル

レビューアプリが動作するには、アプリの GitHub リポジトリのルートに app.json​ ファイルが必要です。app.json​ ファイルは、プルリクエストのオープン時に作成される新しいアプリの設定に使用されます。

アドオンプロバイダーが指定するデフォルトの一時的プランにより、ユーザーが行ったプラン選択が上書きされる場合があります。 デフォルトの一時的プランがアドオンプロバイダーによって指定されている場合、app.json​ で指定した各アドオンの新しいインスタンスは、そのプランを使用してプロビジョニングされます。これにより、プルリクエストをテストするための高速で低コストの依存関係のセットが提供される一方、アドオンパートナーはプロビジョニングコストを抑制できます。

環境設定の継承

レビューアプリでは、その親アプリから環境設定を “継承” できます。app.json​ ファイルでソースに値をコミットする必要はありません。これは、ソース管理には必要ないが、コードをデプロイして実行するために必要な (OAuth クライアントをプロビジョニングするための API_KEY​ や S3 ストレージの AWS キーなどの) 資格情報に便利です。

値の継承を使用できる app.json​ ファイルを作成するには、Dashboard の app.json​ ジェネレーター​ (デフォルトではマスターアプリから継承する) を使用するか、自分自身で継承を指定します。値のないエントリが、親アプリの env からレビューアプリにコピーされます。次に例を示します。

 "env": {
    "INHERIT_THIS_CONFIG_VAR": {
      "required": true
    },
    "DONT_INHERIT_THIS_CONFIG_VAR": "production"
  },

レビューアプリの作成後、app.json​ で指定された postdeploy​ スクリプトを実行すると継承された設定が有効になり、その時点から、OAuth クライアントのプロビジョニングやその他の設定タスクの実行ができるようになります。

required​ (必須) の環境設定と必須でない環境設定のどちらも継承できます。

postdeploy スクリプト

app.json​ ファイルには、postdeploy​ コマンドを指定できる scripts​ セクションがあります。これを使用して 1 回限りの設定タスクを実行し、アプリとデータベースをテストの準備ができていてテストに便利な状態にします。postdeploy は、以下のような 1 回限りのタスクに便利です。

• OAuth クライアントと DNS の設定
• レビューアプリのテストデータベースへのシード/テストデータのロード

Ruby-on-Rails アプリの場合、postdeploy​ コマンドは次のようになります。

bundle exec rake db:schema:load db:seed

この場合、さらに設定しなくてもレビューアプリをテストに使用できるよう、db/seeds.rb​ ファイルによって包括的なデータがデータベースにシードされます。

postdeploy はアプリの作成後に一度だけ実行される

postdeploy​ は、アプリが初めて作成およびデプロイされた後に一度だけ実行されることに注意してください。それ以降に変更がデプロイされても実行されません​。レビューアプリの postdeploy​ スクリプトを再実行するには、プルリクエストをクローズして再度オープンする必要があります。そうすると、Heroku によってレビューアプリが破棄され、再作成されます。

リリースフェーズを使用してプルリクエストの変更のたびにコマンドを実行する

プルリクエストの変更のたびにコマンドを実行するには、リリースフェーズ​を使用します。 リリースフェーズは、CDN へのアセットのアップロード、キャッシュストアの無効化または準備、データベーススキーマの設定と移行の実行などのタスクに役立ちます。 リリースフェーズは postdeploy スクリプトよりも先に実行されます。

pr-predestroy スクリプト

app.json​ ファイルで、必要に応じて pr-predestroy​ スクリプトを指定できます。このスクリプトは、関連付けられたプルリクエストがマージまたはクローズされた後にレビューアプリが破棄されると実行されます。

{
  "name":"Node.js Sample",
  "scripts": {
    "postdeploy": "bin/bootstrap",
    "pr-predestroy": "bin/teardown"
  }
}

postdeploy​ の間にプロビジョニングされたすべてのリソースを破棄したり、その他のクリーンアップを実行したりするには、pr-predestroy​ スクリプトを使用します。

HEROKU_APP_NAME と HEROKU_PARENT_APP_NAME

スクリプト処理に役立つ、2 つの特別な環境設定がレビューアプリで利用できます。app.json​ ファイルで必須またはオプションの環境設定として HEROKU_APP_NAME​ または HEROKU_PARENT_APP_NAME​ を指定した場合、Heroku ではそれらの環境設定を、それぞれ新しいアプリケーション名と親アプリケーション名に設定します。その後、postdeploy​ スクリプトでこれらの環境設定を使用して、より高度なブートストラップと設定を行うことが可能になります。

次に示すのは、HEROKU_APP_NAME​ と HEROKU_PARENT_APP_NAME​ を使用する app.json​ ファイルの例です。

{
  "name":"Advanced App",
  "scripts":{
    "postdeploy":"rake db:setup && bin/bootstrap"
  },
  "env":{
    "HEROKU_APP_NAME": {
      "required": true
    },
    "HEROKU_PARENT_APP_NAME": {
      "required": true
    }
  }
}

レビューアプリの無効化

レビューアプリはいつでも無効化できます。無効化すると、新しいレビューアプリが作成されなくなります。

レビューアプリと CI

パイプラインで Heroku CI​ を有効化している場合、プルリクエストへのすべての後続のコミットで、レビューアプリの更新されたビルドに対してテストが実行されることに注意してください。テスト結果は通常どおり、パイプラインの Tests​ (テスト) タブで確認できます。テストが失敗した場合でも​、更新されたコードがビルドおよびデプロイされます (プルリクエストはもともと実験的なものであるため、Heroku ではレビューアプリへのデプロイはブロックされません)。

以上の規則は、Heroku Pipelines と統合する他の CI システムにも当てはまります。

レビューアプリと Heroku Private Spaces

Private Spaces​ は、dyno や特定の種類のアドオンを、分離されたネットワーク内に閉じ込めた形で実行するための専用環境です。 Private Spaces 内のアプリは、パイプラインのどのステージも占有する可能性があります。

その親が Private Space に存在するレビューアプリは、同じ Private Space (閉じ込めとコンプライアンスが目的の場合) または Heroku Common Runtime (コスト削減が目的の場合) のどちらかで生成および実行できます。

レビューアプリをセットアップするとき、親アプリが Private Space にある場合は、次の追加オプションが表示されます。

レビューアプリと Docker

Dockerfile​ を使用してビルドを定義する場合、heroku.yml​ ファイルをプロジェクトにインクルードする必要があります。 heroku.yml​ がある場合、Heroku は指定された Docker イメージをビルドし、レビューアプリで使用します (app.json​ ファイルはまだ必要です)。

レビューアプリの管理と費用

レビューアプリによって使用される dyno とアドオンは、通常のアプリとまったく同じように課金されます。費用は秒単位で課金され、レビューアプリが存在している時間のみが請求対象になります。

ほとんどの場合、Heroku はデフォルトで、お客様のプランでレビューアプリに利用可能な dyno のうち最も安価なものを使用します。ただし、Private Spaces 内のアプリはデフォルトで private-m​ dyno を使用します。app.json​ ファイルで、デフォルト以外の dyno サイズを指定できます。

レビューアプリが存在するのは、関連付けられたプルリクエストの存続期間中だけであり、アクティブでない状態で 1 日、2 日、5 日、または 30 日が経過したら自動的に破棄されるように設定できます。

アプリを実行およびテストするために、無料または低費用のアドオンプランでも十分な場合は、app.json​ でそれらのプランを指定することもできます。レビューアプリは通常は短命であり、存在している時間分しか請求されないため、月額料金は少額に収まるのが普通です。

自動的に作成されるレビューアプリの費用はすべて、アプリを GitHub に接続したユーザーが請求先になります。レビューアプリを手動で作成する場合、レビューアプリを作成したユーザーが費用の請求先になります。

詳細は、「使用と請求​」の記事を参照してください。

よくある質問

Git サブモジュールは機能しますか?

いいえ。サブモジュールを使用する GitHub リポジトリは一般的に Heroku に正常にデプロイされません。これは、repo-content の tarball が生成される場合は、GitHub にサブモジュールのコンテンツがないためです。

Fourchette とレビューアプリ

GitHub で作成されるプルリクエストに対して Heroku アプリを作成するというアイデアの先駆けは、Rainforest​ と Fourchette です。