チャット経由でデプロイする
最近開発で利用している、デプロイをチャット経由で行うフローについて説明します。
要点
- 開発者はmasterブランチで開発する
- 開発者はデプロイしたいときにBotにお願いする
- Botはmasterブランチからproductionブランチに対してPull Requestをつくる
- 開発者はPull Requestを確認してmergeする
- CIはproductionブランチが変更されるとサーバにデプロイする
ChatOps
masterブランチからproductionブランチにPull Requestを出す作業は面倒なので、チャット経由で行っています。Heroku上で動かしたRubotyにruboty-githubとruboty-aliasというプラグインを入れて、「デプロイしたい」と発言するとPull Requestを作成するように設定しています。チャット経由で物事を行うようにすると、周知や教育としての効果も少し期待できます。
Pull Request
Pull Requestベースでデプロイを行うと、Pull Request上で差分やCIの状況を確認できたり、コミュニケーションを行えたり、記録が残ったりという利点があります。デプロイ用のPull Requestにラベルを付けて管理しておいたり、Pull Requestのmergeをチャットに通知するようにしていれば、開発の進捗が俯瞰しやすくなるかもしれません。
ブランチ戦略
これまでGitHub Flowを利用していたため、現状はこれにproductionブランチを加えた構成になっています。しかしmasterブランチの開発速度が非常に速い状況下では、これからデプロイされるコードへのテストと確認が容易ではなくなります (masterをテスト・確認しようとしたら次の変更がmasterに追加され、また最初から確認し直す必要があるなど)。
この場合は、Git-Flowに代表されるようなリリースブランチをつくり、リリースブランチからproductionブランチにPull Requestを送る方が、より厳格な開発フローになると思います。チャット経由ならこの辺りの複雑な処理は隠蔽できるので、モバイルアプリの開発フローと足並みを揃えるにはこちらのフローの方が良いかもしれません。規模・コスト・習熟度によって適切な運用方法は異なるものになるため、より単純なフローから試していくというのが良いと思います。
CI
デプロイはCI上で cap production deploy を実行しています。Pull Request同様、過去のデプロイやデプロイ失敗時のログが残るので、問題解決に役立ちます。Herokuを使っている場合は、CIでデプロイする代わりにGitHub Syncの機能を有効化しても良いでしょう。また開発者の手元でデプロイする場合に比べ、個々人の環境に依存した問題が起きにくくなります。一方、CI用のサービスが落ちたときにデプロイ出来なくなっては困るので、ローカル環境からデプロイ出来る状態にしておくことも大切です。
障害
もし外部のサービスを利用する場合は「このサービスが落ちるとこれが出来なくなる」という情報は予め整理し、対策を用意すると共にどの程度諦めるかを考慮しておいた方が良いでしょう。例えば、もしHeroku、Slack、GitHub、CircleCIが落ちた場合、Botも反応せず、チャットにも繋がらず、Pull Requestも作れず、CI経由でのデプロイもできず、コードの取得もできませんが、Capistranoのデプロイ方法をrsync経由に変更し、手元で cap production deploy を実行すればデプロイは可能です。
おわり
デプロイをチャット経由で行うフローについて説明しました。余談ですが、Botは擬人化するよりゆるキャラ化する方が良い文化を育みやすいと思っています。そのうち、開発もレビューもデプロイも全部Botがやってくれるようになると良いですね。