こんにちは、浅野です。
今日は、8月以降に始まる開発案件(Heroku上にWebアプリを乗せる)でこんな風に開発を進めよう、と考えている開発のフローについて書きます。
目的
このPOSTでは、GitHubのリポジトリとHerokuを使った開発で、手動でのHeroku環境へのデプロイを減らしつつ、開発・テスト等の活動の並行性を維持するために、HerokuのGitHub連携機能をどう使うか、を整理します。
書くこと
Heroku上に乗せるアプリは以下の3つの環境を用意する想定です。
- dev 開発環境。開発の最新版
- staging 検証環境。リリース候補のテストを行う
- production 本番環境。リリースされたもの
これらの環境に、いつ、なにを、どうやってデプロイするのかを考えます。
ブランチ戦略
何をデプロイするか、はブランチ戦略に密に関わってくるので、まず想定しているブランチ戦略を書きます。
ブランチ戦略は基本的にgit-flowを踏襲します。 git-flowについてはこちら(A successful Git branching model を翻訳しました)が詳しいです。
踏襲しない所 * 元々はサポートブランチになっている release ブランチを、メインブランチと同じくずっと存在し続けるものとします(理由は後述します)。混同を防止するために名前をstagingブランチとします。 * hotfixブランチは上記の変更に伴って、stagingブランチから作ってマージする。
各ブランチ間での変更の取り込みは、全てプルリクエストを介して行うように想定します。
図にすると下記のようなイメージです。
ブランチ間の関連図
デプロイ戦略
メインブランチのデプロイ
基本的に、それぞれの環境に対応するブランチに対してプルリクエストが受け付けられたタイミングで自動デプロイするようにします。 これは、それぞれの環境に対応するHerokuアプリケーションを作って、GitHub Integrationの automatic-deploysを設定します。
各環境とブランチ、アプリ名の対応は以下のようにします。
| 環境 | 対応ブランチ | アプリ名 |
|---|---|---|
| dev | develop | dev-xxxxxx.herokuapp.com |
| staging | staging | staging-xxxxxx.herokuapp.com |
| production | master | xxxxxx.herokuapp.com |
ここで「後述します」と言っていたreleaseブランチをメインブランチ相当にする理由を説明します。 git-flowを踏襲すると releaseブランチはリリースの度に作られて消えてしまいます。Herokuの automatic-deploys で指定するブランチが都度作られて消えてだと毎回設定を変える必要あるので、 設定そのままで自動デプロイするためにstagingブランチをずっと保持し続けるようにしています。
サポートブランチのデプロイ
サポートブランチの自動デプロイは ReviewAppを使ってデプロイします。 このReviewAppは、dev環境のHerokuアプリケーションに設定して、DB接続先などの環境変数情報はdev環境のアプリケーションと同じ値を使用します。
少し悩ましいのは、development -> staging, staging -> master といったメインブランチからメインブランチへのプルリクエストもおそらくReviewAppで対応するHerokuアプリケーションが作られてしまう事ですが、マージされたタイミングでアプリが消滅するので気にしない事にします。
これを先ほどのブランチ戦略の図に重ねるとこのようになります。
ブランチ・デプロイの図
まとめ
HerokuのGitHub Integration機能を使うとこのようにGitリポジトリのブランチとHeroku上のアプリケーションを自動で同期させることが可能です。「デプロイする」行為をほぼ意識しなくて済むのは楽でいいですね。