Pull Request毎に動作確認環境が提供されるHerokuのReview Appsを使ってみた話

こんにちは、エンジニアの @akase244 です。この記事はイノベーター・ジャパンAdvent Calendar 2018の19日目の記事です。

当社ではGitHubのPull Request（以下PR）をエンジニア同士でコードレビューしているのですが、その際に実際に動かして確認したいという場合があります。
自分が携わっている案件であればローカルに開発環境が揃っているので、PRの対象ブランチに切り替えればすぐに確認可能なのですが、さすがに全てのプロジェクトに関わっているわけではありません。
動作確認のために各案件のGitHubリポジトリに収録されているVagrantfileやDockerfileでプロビジョニングしてもよいのですが、これはこれで時間が掛かったりしてなかなか。。。

前回の記事で触れたとおり、現在私が関わっている案件ではHerokuを利用しています。
Herokuには「Review Apps」という機能があり、これがまさにGitHubのPR単位で動作確認環境を提供してくれる機能となっています。これは使わないともったいないと思い、今回はHerokuのReview Appsを試してみた話です。

Heroku Review Appsとは

f:id:akase244:20181212165640p:plain

Heroku Review Appsは2015年5月19日にBetaリリース、2016年4月18日にGenerally Availableとしてリリースされており、以下のような特徴があります。

GitHubのPR毎にURLを発行し動作確認環境を提供する。
PR作成時に自動的にReview Apps環境を構築することが可能。
RPがマージもしくはクローズされると自動的にこの環境は削除される。
「◯日後に自動的に削除」といった設定が可能。
Review Apps環境の設計図となる「app.json」に記述することで環境変数、buildpack、Add-ons等を定義することが可能。

Heroku Review Appsの設定方法

GAリリースが2年前ということもあり、設定方法に関する有用記事は当然たくさんありますので、詳細な説明についてはそれらの記事を参照するとよいでしょう。
また、Herokuはドキュメントが非常に充実しているので、Review Appsのドキュメントを見るのが実は一番近道だったりします。

気になったところなどなど

料金について
- 料金についてはドキュメント内に「review apps are typically short-lived, and you are charged only while they exist, monthly charges are typically small.」との記載があるとおりReview Apps環境が起動している間は課金されます。Review Appsの元となっているアプリがたとえFree Dynos（無料プラン）であっても検証環境として提供しているものなのでスリープ状態（Free Dynosは30分でスリープ状態に入ります）になりません。
- app.json の書式によりAdd-onsのプランまで指定できるので、Review Apps環境で利用するAdd-onsを無料で抑えたい場合はプランまで指定するのが吉。
app.jsonについて
- 環境変数の値が空の項目を app.json でうっかり required:true にしておくとReview Apps環境の構築時にエラーが発生します。
DB(ClearDB)について
- HerokuのRelease Phase機能を利用してDBのマイグレーション処理をデプロイ時に行っているのですが、DBの接続先環境変数(CLEARDB_DATABASE_URL)を required:true にしておくと本番環境のDBに対してマイグレーションが実行されてしまいます。（この件の前提として、CLEARDB_DATABASE_URLはDBのバージョンアップなどの際にカジュアルに値が変更されるのでこの内容と同じような対策をしているという背景があります）
- マイグレーションの適用先が本番環境のDBであることを認識した上で、Review Appsで本番のデータを利用しながら検証を行うというのであればよいですが、マイグレーションについては不可逆なものもあるので、このあたりは要注意といったところでしょうか。
- app.json でAdd-onsのClearDBを利用するように指定している場合に、 CLEARDB_DATABASE_URL の環境変数を required:true にしておくと、 CLEARDB_DATABASE_URL とバッティングしないような配慮だと思いますが CLEARDB_*****_URL といった環境変数（例：CLEARDB_JADE_URL、CLEARDB_COPPER_URL、CLEARDB_WHITE_URL）が新たに生成され、 CLEARDB_*****_URL に定義されているDBがReview Apps用として作成されます。
postdeployについて
- Review Appsの環境に初期データの投入を行いたい場合は app.json の postdeploy に記述することで対応可能です。
- postdeploy scriptはReview Appsの環境でのみ実行され、実行順序としてはRelease Phaseの後に実行されます。

まとめ

今回Review Appsを使ってみて感じたことは「app.json を制すものはReview Appsを制す」といっても過言ではないなと。
Review Apps環境の構築方法を理解する前は元となるアプリをコピーするイメージだと思っていましたが、そうではなくてコピーするのものは app.json に記述されている環境変数の内容だけで、後は app.json の記述内容に従い新たな環境の上にbuildpackの設定を行い、Add-onsで利用するものをインストールし、PRのソースコードを適用し、初期データを投入するといった感じでしょうか。

そして、本来の目的の話に戻りますが。。。今回動作検証に利用したPRは「ユーザー登録の際に既存の保存項目とは別に新たな項目をDBに保存する」という修正内容のものを採用しました。
本番環境で動かすと（まぁ当然ですが）追加の項目が記録されず、Review Appsの環境で動かすと追加した項目が記録されるという動作の違いが確認できました。
ということで、Herokuを利用している環境であればReview AppsはPRの動作確認を行うには非常に強力な機能だと思いますので、みなさんもぜひ使ってみてはいかがでしょうか。

明日の担当は penta さんです。去年は「英語」にフォーカスした話題だったけど、今年はどんな内容だろう？ということで引き続きイノベーター・ジャパンAdvent Calendarをお楽しみください。