Heroku Flowをざっくりまとめる

> Heroku Flow は、Heroku Pipeline、レビューアプリ、Heroku CI、GitHub を構造化された使いやすいワークフローに統合し、継続的デリバリーを実現します。

[GitHub&Pipelines を利用したクラウド上の継続的デリバリ | Heroku](https://jp.heroku.com/flow)

要はデプロイ周りのフローを良い感じにしてくれます。

## 構成要素
以下、Heroku Flowを構成する要素の説明です。

### Heroku Pipeline
masterブランチにマージされたら、ステージング環境にデプロイして、確認して問題がなければ本番環境に反映する、みたいな流れを簡単に作ることができる。
ステージング→本番に反映する時、スラグを反映するので、通常のデプロイより実行時間が短くすむ。

[Step 5: Herokuパイプラインでステージング環境を用意しよう！ · Meteor アプリを Heroku にデプロイしよう！](https://j-hack.gitbooks.io/deploy-meteor-app-to-heroku/content/step5.html)

### Heroku CI
masterブランチにマージされた時にテストを走らせることができる。設定が簡単。
月10ドル + dyno利用料がかかるのが個人開発者にとってはネック。
普通にCircle CIで良い気もする。

### レビューアプリ
プルリクが上がる度に自動or手動でそのプルリクの変更を反映した環境を作成できる。
レビューの効率が上がる。

### Heroku ChatOps
HerokuのログをSlackに通知したり、ステージング環境で確認が取れたアプリをslackから本番に反映(promote)したりできる。

[HerokuのChatOpsが便利 - チラシ裏日記上等！！新館](https://www.chirashiura.com/entry/2017/06/22/080000)

### リリースフェーズ
デプロイの時に実行するタスクを指定できるやつ。
DBのマイグレーションコマンドを実行したり、CDNにコンテンツをアップロードする作業を自動化できる。

[リリースフェーズによる ToDo の実行 単元 | Salesforce Trailhead](https://trailhead.salesforce.com/ja/content/learn/modules/heroku-flow/run-tasks-with-release-phase)

## デプロイフローの例
以下、上述の機能を活用したデプロイフローの例です。

1. プルリクをmasterブランチにマージ
2. 自動的にHerokuのステージング環境にデプロイされる(マイグレーションも自動で実行される)
3. 動作を確認し、問題がなければslackからpromoteを実行(マイグレーションも自動で実行される)
4. slackに届く通知で、本番に反映されたことを確認

現在私は個人開発での利用を検討しているので、CIとレビューアプリは使いません。
CIを使う場合は1の前のプルリクを上げたタイミングでテストが走り、
レビューアプリを使う場合には、1と2の間にレビューアプリでの確認が追加されます。

## 個人的に嬉しいポイント
- マイグレーションが自動で実行される
- masterにマージしたら自動でステージング環境にデプロイされる
- ステージング環境で動作を確認できる
- ステージング→本番への移行がSlackで文章を送信するだけ
- デプロイの履歴が全てslackに残る
- 上記が簡単に設定できる

## 設定
### ステージング環境用のアプリを作成
本番環境からforkします。まずは`heroku fork`コマンドを有効化するためのプラグインをインストール。

```zsh
$ heroku plugins:install heroku-fork #heroku forkコマンドを有効化
$ heroku fork --from app-name --to app-name-stg
```
これで本番環境と同じプログラム、環境変数、アドオン、DB内のデータを持った環境が出来上がります。
Dynoやアドオンは全て無料プランのものに自動的に変更されているようです。

### 新しいパイプラインの作成
- 本番環境のダッシュボードを開く
- Deployタブ > Add this app to a pipeline > Choose a pipeline > Create a new pipelile > pipeline名を入力し、productionのアプリとして登録
- staging環境のアプリとして、ステージング用のアプリを登録

### 自動デプロイの設定
masterブランチにマージされた時、自動的にステージング環境にデプロイされるように設定します。

- ステージング環境のHerokuダッシュボードを開く
- Deployタブ > Deployment method > GitHubをクリック
- ブランチを選択して連携
- Enable Automatic Deployをクリック

### 動作確認
- 適当な変更をmasterブランチにマージして、ステージング環境でのみ表示が変わっていることを確認
- 本番環境にpromoteして、本番に反映されることを確認

### Heroku ChatOpsの導入
- [Heroku ChatOps]の公式ページを開く
- Getting Startedの項目から「Add to Slack」ボタンをクリック
- Slackと接続
- Slackを開き、適当なチャンネルで`/h login`と入力
- 「Heroku、GitHubそれぞれと連携しろ」という内容のメッセージが表示されるので、指示に従って連携
- Slackを開き`/h route [pipeline名] to #[通知を受け取るチャンネル名]`と入力し送信

これで連携は完了、以下使えるコマンドの抜粋です。

```
ステージング→本番にpromote(反映)
/h promote sample-pipeline

notificationチャンネルに通知を受け取る設定
/h route sample-pipeline to #notification
 
最近のリリース情報の確認
/h releases sample-pipeline

最近の本番環境のリリース状況を確認
/h releases sample-pipeline in production

pipelineの情報を確認
/h info sample-pipeline
```


### 動作確認
- 適当な変更をmasterブランチにマージ
- ステージング環境にデプロイされた通知がSlackに届くことを確認
- Slackに`/h promote sample-pipeline`と入力
- 本番環境に変更が反映されていることを確認
- 本番環境にデプロイされた通知がSlackに届くことを確認

### リリースフェーズの導入
ドキュメントルートに`Procfile`という名前のファイルを作成し、以下を記述。

```
release: bin/rails db:migrate
```
今回はRailsのマイグレーションを自動化したいので`bin/rails db:migrate`と入力しました。
適宜好きなコマンドに置き換えてください。

### 動作確認
- ステージング、本番の両方のDBの状態を確認できるようにしておく
- マイグレーションを伴う変更をmasterブランチにマージ
- Staging環境でマイグレーションが反映されていることを確認
- 本番環境にPromote
- 本番環境でマイグレーションが反映されていることを確認