Heroku パイプラインの作成とレビューアプリケーションの実行
学習の目的
この単元を完了すると、次のことができるようになります。
- パイプラインで使用できるオプションについて説明する。
- レビューアプリケーションの利点を説明する。
パイプラインのフェーズ
パイプラインの各アプリケーションは、継続的配信ワークフローでのレビュー、開発、ステージング、本番というステップのいずれかを示しています。
開発者が最もよく知っているフェーズは次の 2 つです。
-
ステージング: ステージングでは、変更を本番にリリースする前に本番と似た環境でテストします。
-
本番: 本番環境のアプリケーションをエンドユーザーが使用できます。
この 2 つのフェーズのほかに、個々のコード変更とプルリクエストをより簡単に確認するために開発者がよく使用するフェーズが少なくとももう 1 つあります。ほとんどはこの種のテストに次のフェーズのいずれかを使用します。
-
レビューアプリケーション: このオプションは、GitHub インテグレーションを使用し、パイプラインでレビューアプリケーション機能を有効にしている場合にのみ使用できます。開発者は変更をプッシュして一時的で共有可能なアプリケーションを作成し、特定のプルリクエストをテストします。この機能がない場合、開発者は代わりに変更を開発フェーズにプッシュして共有することができます。
-
開発: 開発者はローカルマシンでコード変更を作成してテストできます。必要に応じてこのコードを Heroku のパイプラインの開発フェーズにプッシュして他のユーザーと共有できます。
パイプラインの各フェーズに複数のアプリケーションを含めることができます。たとえば、遅延を軽減するために、コードベースが同じでリリース先のリージョンが異なる 2 つの本番アプリケーションが含まれることがあります。
パイプラインを作成してアプリケーションを追加する場合は、Heroku 開発センターの「パイプライン」を参照してください。
レビューアプリケーションを有効化して使用する
コードを GitHub に追加したら、リポジトリに接続してパイプラインのレビューアプリケーションを有効化できます。有効化すると、新しいプルリクエストがオープンになるたびに一時的なテストアプリケーションを手動または自動で実行できます。PR がクローズするとレビューアプリケーションは自動的に破棄されます。期限切れのアプリケーションをいつ削除するかを選択して使用をさらに削減することもできます。この機能に関連する手順と費用については、Heroku 開発センターを参照してください。
レビューアプリケーションでは app.json ファイルを使用してアプリケーションを設定します。レビューアプリケーションを有効化する前にこのファイルをコードに追加します。詳細は、Heroku 開発センターの設定に関するセクションと app.json のスキーマを参照してください。
app.json ファイルは GitHub のコードに含まれるため、機密性の高い設定変数値は追加しないでください。代わりに、パイプラインの [Settings (設定)] タブでそれらの値を設定変数として設定します。
Heroku アプリケーションと同様に、各レビューアプリケーションには固有の URL があり、ブラウザーに入力して表示できます。パイプラインのページのレビューアプリケーションの横にある [Open app in browser (アプリケーションをブラウザーで開く)] をクリックして変更をすばやくプレビューすることもできます。レビューアプリケーションの設定時に、ランダムと予測可能のどちらの URL パターンを使用するか選択できます。予測可能な URL の場合、Heroku では選択されたプレフィックスとプルリクエスト番号を使用してアプリケーションを作成します。たとえば、プレフィックス example-prefix を選択した場合、プルリクエスト番号 123 をオープンすると example-prefix-pr123.herokuapp.com にレビューアプリケーションが作成されます。
Heroku CI を有効化する
Heroku のネイティブ CI 機能は各パイプラインで有効化できます。CI テスト実行中に使用される dyno とアドオンにより追加費用が発生します。
Heroku CI を使用するには GitHub インテグレーションが必要です。[Settings (設定)] タブでパイプラインをリポジトリに関連付けて Heroku CI を有効化します。
Heroku CI 環境を設定するには、リポジトリのルートディレクトリに app.json マニフェストを追加します。CI テストの実行中は、このファイルの test 環境に定義されているキーが、アプリケーションの基本設定に含まれる一致するキーよりも優先されます。
ステージングへの自動リリースを設定する
継続的配信を使用すると、すべての変更がステージングにプッシュされます。ステージングアプリケーションで自動リリースを有効化すると、コードが特定のブランチにマージされるときは常にこのステップを自動化できます。
GitHub インテグレーションを使用している場合、アプリケーションの [Deploy (リリース)] タブで自動リリースを設定できます。Heroku CI を使用している場合、Heroku CI で合格した場合にのみ自動リリースが行われるように設定できます。詳細は「GitHub インテグレーション」を参照してください。
ステージングから本番に昇格する
パイプライン昇格を使用するリリースは、ステートレスビルドのアプリケーションにのみ推奨されます。スラッグはアプリケーションを圧縮して事前にパッケージ化したコピーです。本番に昇格するとき、Heroku ではスラッグを変更せずにステージングからコピーします。本番用のリビルドではありません。ビルドで設定変数値をスラッグにコンパイルすると、昇格時に問題が発生することがあります。ステートフルビルドのアプリケーションの場合、代わりに Heroku 標準の Git ベースのリリースか GitHub リリースを使用してください。
パイプラインページには、視覚的なアプリケーションの進行状況が、各フェーズの状況に関するメタ情報と一緒に表示されます。たとえば、本番アプリケーションがステージングと異なるコードを実行しているかどうかを確認できます。昇格するステージングアプリケーションの [Promote to production (本番に昇格)] をクリックします。
ここでは、パイプラインでアプリケーションをどう操作するかについて学習しました。次は、リリースフェーズとリリースのしくみについて学習します。
リソース
