ボクココ

サービス開発を成功させるまでの歩み

Heroku Pipeline にステージング環境を乗せてみた

ども、@kimihom です。

今回はステージング環境と本番環境で Heroku アプリを分けていたものを、 Heroku Pipeline でまとめたのでその手順についてご紹介する。

今まで Heroku Pipeline を勘違いしていたんだけど、ステージング環境の Heroku アプリは Heroku アプリの設定を保ったまま残る。つまり、アドオンや、アドオン内で保存されたデータなどはそのまま保たれるということを意味する。ステージング環境と本番環境の切り替えだけの場合は特に大きな変更をすることなく Pipeline へ移行できた。

RAILS_ENV での環境切り替えは非推奨

Rails アプリは、 RAILS_ENV の環境変数によって、読み込みに行く config/environments/~.rb を変えてくれる。これをうまく利用して、Heroku の RAILS_ENV を staging にすると、config/environments/staging.rb を読み込んだ状態でアプリを起動してくれる。また、Rails.env.staging? といったメソッドを利用できるため、コード内で ステージング環境と本番環境を分けたコードを書くことができる。

ただし、この方法は Heroku では非推奨とされる。このようなアプリを書いて Heroku にデプロイすると、以下のような警告が表示される。

f:id:cevid_cpp:20170626005319p:plain

Heroku アプリは全てproduction環境であるべきとされ、アプリごとの差分は環境変数で管理しなければならない。デプロイするたびにこの警告を見るのは気分がよろしくないから、思い切って同じ Production 環境の Heroku アプリとして Heroku Pipeline に移しつつ、警告が出る問題をクリアしようってわけ。

既存本番アプリに Pipeline を作成

さて、Heroku Pipeline を使ってみよう。Heroku Pipeline を使えば修正内容を ステージング環境でチェックしたら 本番へデプロイするみたいな流れを Heroku と Github のプルリクエストで管理できるようになる。それぞれの Heroku アプリは継続的デリバリーのワークローとして例えば以下のようなステップで表すことができる。

  • Review
  • Development
  • Staging
  • Production

ひとまず、本番環境で運用する Heroku アプリの画面から Heroku Pipeline を有効にしよう。

f:id:cevid_cpp:20170625225354p:plain

そんで Pipeline の画面に行ったら、Add Existing App をクリックし、既存で管理してた別のステージング環境のアプリを指定する。

f:id:cevid_cpp:20170626003549p:plain

無事追加すると、Heroku のアプリ一覧は以下のような感じに統合される。2 Apps となって一緒のアプリになった感が出たね!そして Pipeline には Staging でのアプリが表示されるようになった。

f:id:cevid_cpp:20170626003759p:plain

f:id:cevid_cpp:20170626004304p:plain

本来ならこれで Github と連携すれば、プルリクエストに応じてパイプラインのアプリが Heroku にデプロイされ、Accept すると勝手に Staging から Production へ昇格させたりできるらしいけど、Bitbucket での運用の場合は普通に git push heroku master とかでデプロイする感じになる。つまり、今までと特に何も変わらないってこと。今後 Heroku の Bitbucket 対応を待つか、諦めて Github にお金を払ってプライベート環境を用意するかになりそうである。

ソースの修正

さて、Bitbucket Pipeline はこのくらいにしておいて、Heroku デプロイの際に表示されるあの忌まわしい Waring を消す作業をしていこう。

これを実施するには、以下のような流れとなる。

  1. config/environments/staging.rbconfig/environments/production.rb の差分を確認
  2. 適宜 環境変数に置き換える
  3. その他コードで Rails.env.staging? のコードを探し、必要に応じて環境変数に置き換える
  4. デプロイ
  5. ステージングアプリで heroku config:set RAILS_ENV=production を適用   環境ごとの差分は staging, productionif 文で切り替えるのではなく、ENV環境変数 で切り替えよう。ここはソースを grep しながら、慎重に修正していかないといけない。

1 の environments の切り替えで特にオススメしたいのはログレベルの設定だ。LOG_LEVEL=infoが本番、LOG_LEVEL=debug がステージングって感じにして config/environments/production.rbconfig.log_level = ENV['LOG_LEVEL'].to_sym にしておくと何かと便利である。

これでステージング環境に Heroku をデプロイすると、見事警告を消去することができた!Heroku に怒られないようになったのはとても喜ばしいことである。

終わりに

今回は、本番環境とステージング環境を別々で管理していた Heroku アプリケーションを、 Heroku Pipeline 上で一まとまりとして管理できるようにした。さらに個々のアプリを 環境変数で対応するようにすることで、デプロイ時の警告を消去することに成功した。

Heroku Pipeline のより具体的な運用事例に関しては、前回の Heroku Meetup の tambourine の安部さんの発表資料を見るといいと思う。

www.bokukoko.info

それでは素敵な Heroku ライフを。