最終更新日 2020年08月06日(木)

Heroku アプリは、少なくとも次の 2 つの環境で動作します。

• ローカルマシン上 (開発​)
• Heroku プラットフォームにデプロイ済み (本番​)

アプリは、次の 2 つの追加の​環境で動作することが理想的です。

• テスト​。アプリのテストスイートを分離して、安全に実行するため
• ステージング​。アプリの新しいビルドを、プロモートする前に本番同様の設定で実行するため

これらの個別の環境を異なる Heroku アプリとして保持し、各環境をその意図した目的にのみ使用すると、バグの多いコードが本番環境にデプロイされないようにするのに役立ちます。

Heroku の Linux スタック​は開発用マシンのオペレーティングシステムとは異なる可能性があるため、この方法は特に重要です。つまり、ローカル開発環境で動作するコードが、本番環境でまったく同じように動作すると確信することはできません。

Heroku には、アプリのステージングおよびテスト環境を作成して保持するための役立つツール (つまり、パイプライン​、Heroku CI​、レビューアプリ))​ が用意されています。

環境の作成とリンク

ステージング環境の作成

ローカル (開発用) マシンで動作するアプリケーションがあり、それを Heroku にプッシュする準備ができているとしましょう。Heroku CLI​ を使用して、ステージング環境を表す新しい Heroku アプリを作成できます。

$ heroku create --remote staging
Creating strong-river-216.... done
http://strong-river-216.heroku.com/ | https://git.heroku.com/strong-river-216.git
Git remote staging added

デフォルトでは、Heroku CLI は、リポジトリに heroku​ という名前の Git リモートを追加します。上記のコマンドでは、--remote​ フラグを使用して、リモートのための異なる名前 (この場合は、staging​) を指定しています。そのため、コードをアプリの新しいステージング環境にプッシュするには、次のコマンドを使用します。

$ git push staging master
...
$ heroku ps --remote staging
=== web: `bundle exec puma -C config/puma.rb``
web.1: up for 21s

本番環境の作成

ステージングアプリが正しく稼働したら、同じコマンドを使用して本番環境を作成し、そこにプッシュできます。

$ heroku create --remote production
Creating fierce-ice-327.... done
http://fierce-ice-327.heroku.com/ | https://git.heroku.com/fierce-ice-327.git
Git remote production added
$ git push production master
...
$ heroku ps --remote production
=== web: `bundle exec puma -C config/puma.rb``
web.1: up for 16s

これで、2 つの個別の Heroku アプリ (ステージングに 1 つと本番に 1 つ) として実行される同じコードベースが用意されました。

Heroku CLI での環境の指定

Git リポジトリに複数の Heroku リモートが関連付けられている場合、Heroku CLI のコマンドでは、-r​ (または --remote​) オプションを含めることによって対話するアプリを指定する必要があります。ワークフローを簡略化するために、Git 設定を編集してデフォルトの Heroku リモートを示すことができます。

たとえば、次のコマンドを使用して、staging​ をデフォルトの Heroku リモートにすることができます。

$ git config heroku.remote staging

これにより、プロジェクトの .git/config​ ファイルに次のセクションが追加されます。

[heroku]
  remote = staging

この変更を行った後、リポジトリから実行するすべての Heroku CLI コマンドが、デフォルトで staging​ アプリを管理します。production​ アプリに対してコマンドを実行するには、そのコマンドに -r production​ を含めるだけです。

パイプラインでの環境のリンク

Heroku パイプライン​により、アプリの環境をリンクし、ステージングから本番にコードをプロモートすることが簡単になります。

この手順​に従って、Heroku Dashboard から新しいパイプラインを作成し、それにステージングおよび本番環境を追加します。

ステージングおよび本番設定の管理

多くの言語やフレームワークでは、開発/本番スイッチの切り替えがサポートされています。 たとえば、開発モードでは、別のデータベースを使用したり、ロギングレベルを上げたり、すべてのメールをエンドユーザーではなく自分自身に送信したりすることができます。

アプリケーションが使用するサービスやライブラリでも、独自の環境設定を設定して、本番環境でこれらをミラーリングすることが必要になる場合があります。 たとえば、ステージングでは本番とは別の S3 バケットを使用できるため、次の鍵に別の値を使用します。

$ heroku config:set S3_KEY=XXX --remote staging
$ heroku config:set S3_SECRET=YYY --remote staging

高度: ローカルブランチのリモートアプリへのリンク

上記の手順に従っている場合、git push staging master​ と git push production master​ を入力することは簡単です。ただし、多くの開発者は Git のブランチを利用して、進行中のコードと本番準備完了のコードを分離することを好みます。この種類の設定では、master​ ブランチから本番環境にデプロイし、development​ ブランチの変更がステージングアプリで確認されたらそれらの変更をマージすることもできます。この設定で、プッシュは少し注意が必要です。

$ git push staging development:master

このコマンドは、Git にローカルの development​ ブランチから staging​ リモートの master​ ブランチにプッシュするよう指示します(これは少し乱雑に見えるかもしれませんが、実際にはこれより多くの処理が行われています。refspec についての詳細は、Git の書籍​を参照)。

Git コマンドを簡略化したい場合は、ローカルの Git ブランチに強制的にリモートアプリケーションを追跡させることにより簡潔にすることができます。staging​ と production​ の Git リモートを取得している場合は、次のようにできます。

$ git config push.default tracking
$ git checkout -b staging --track staging/master
Branch staging set up to track remote branch master from staging.
Switched to a new branch 'staging'

これで staging​ ブランチに入っているため、git pull​ と git push​ がそれ以上の引数なしでステージング環境に対して機能するように設定されました。コードを少し変更し、それをコミットしてプッシュします。

$ git commit -a -m "changed code"
$ git push
Counting objects: 11, done.
...

git push staging staging:master​ ではなく、git push​ を入力したことに注意してください。これは push.default​ 設定によって可能になります。それが tracking​ に設定されていると、ローカルブランチでは、追跡しているリモートリポジトリに変更が自動的にプッシュされます。

ローカルの master​ ブランチが production​ リモートを指すようにしたい (かつ、Git 1.7 以降を実行している) 場合は、次のようにできます。

$ git fetch production
$ git branch --set-upstream master production/master

その場合は、master​ からの git push​ によって Heroku 上の本番アプリが更新されます。