はじめに
こんにちは。EventHubの西内です。
今回はEventHubで開発した機能がどのようなフローで本番環境にリリースされるかについて、ご紹介できればと思います。
採用面接の際、リリースフローに関する質問をいただくことがありますし、質問はせずともCI/CDがどんな感じなのか知っておきたい方もいるかと思いますので、ぜひ参考にしていただければなと考えています。
記事のスコープ
話すこと
- 開発サイクル
- ブランチの運用フロー
- CI/CDの概要
話さないこと
- リリース後の話
- 開発着手前や着手中の細かい話
開発サイクル
EventHubでは週に1度リリースを行うサイクルで開発を行っています。
そのサイクルでリリースを行えるようにするために日々テストコードをメンテナンスしており、何らかの機能開発や修正を行ってもデグレードが起きていないことをできる限り確認できるようにしています。
さらに本番環境（production）と同等の構成で検証可能なQA環境（qa)を用意しており、そこでテストを行ったり開発以外の部署に方に触ってもらったりもしています。
開発サイクルの話題を冒頭に持ってきた理由としては、どのぐらいの速度感でプロダクトをデプロイしていきたいかがブランチの運用やリリースフローといった設計の妥当性に関わると考えているからです。
ブランチの運用とリリースフロー
先程の開発サイクルは、以下の図のようなブランチ運用によって成り立っています。
なお、ローカルでのブランチ運用に関してはエンジニアによって異なるので、一例として捉えていただければと思います。
- 開発時にはmainブランチから開発用にローカルブランチを作成
- 開発が済んだらPull Requestを作成してレビューを行い、2件以上の承認を得たらmainにマージ（Squash）します
- ちなみにEventHubではtopicブランチごとに動作確認が可能な環境がAWS上で自動的に構築されるので、その環境を使って都度検証を行います
- 週に1度、mainブランチでリリースバージョンのタグを作成し、それを元にしてqaブランチ向けにPRを作成
- productionブランチ向けのPRは前回リリース後に、その時点のqaブランチを元にして作成してあります
- その後、qaとproduction向けのPRをマージしておき、リリースに備えます
- 翌日のリリース予定時刻になったら、qaとproductionのCIを開始させて自動デプロイ
このフローは私が入社（2023年6月）するよりも前から存在しており、ブランチ運用やリリースフローのドキュメントの履歴を見ると2021年9月には既に出来上がっていたようで、そこからほぼ変わっていないみたいです。
さて、ここまで紹介してきたEventHubでのブランチ運用やリリースフロー、および開発サイクルですが、以下のような良さがあるのではないかと考えています。
- 機能追加や修正内容に応じてヘルプページの作成/編集などを行う猶予がある
- 週に一度Sprint Reviewと称して、QA環境や本番環境にリリースされる内容を社内に共有しています。小さい追加修正などはそこで初めて知ることがあるものの、実際にリリースされるまでの時間があるのでヘルプページの作成/編集や特定の顧客への連絡などが必要であっても、うまく回せていると感じています
- 別の機能を開発中にQA環境でも発生する不具合が見つかったら、本番環境にリリースされるまでの間に修正ができる
- だからといって、普段の検証をおろそかにしてもいいわけではないのですが、リカバリー可能であることで多少は心に余裕ができますね
- いわゆるトランクベースな開発のメリットを一部享受できる
- わかりやすい例としてはコンフリクトが起きづらくなりますし、PullRequestも小さくなるのでレビューしやすくなることでしょうか
mainブランチにマージしてから約2週間後に本番環境へリリースされるわけですが、もしかすると人によっては遅いと感じられたりするかも知れません。
しかし、以上のような事柄を加味すると、ちょうど良いサイクルなのではないかなと私は感じています。
CI/CDの概要
EventHubではCI/CDのツールとして、Circle CIを採用しています。
CI/CDにはQA環境や本番環境へのデプロイ以外に、日々の開発を支えるパイプラインも用意しています。開発ブランチ用のパイプラインでは、主に「自動テスト」と「ブランチごとの検証環境構築」のJOBが実行されるようになっています。
EventHubの自動テストの種類の割合は、バックエンドのコードに対してのテストがざっくり90%を占めているのではないかと思います（カバレッジ等の指標は追っていないため個人の感覚です）。
もちろん、フロントエンドでも必要であればコンポーネントのテストを書いたり、独立したfunctionのテストを書いたりすることもあります。また、ヘッドレスブラウザを使ったEnd-to-Endの自動テストを書くこともあります。
また、EventHubのリポジトリはモノレポの構成を採用しているため、フロントエンドとバックエンドのソースコードが1つのリポジトリで管理されています。このモノレポの良さの1つとして挙げられそうなのは、CI/CDの構築のしやすさがあるのではないかなと感じています。
先程も少し触れましたが、topicブランチごとに動作確認が可能な環境がAWS上で自動構築されるようになっています。
こういった仕組みを異なるリポジトリを組み合わせて行おうとすると、なかなか複雑なものになると思いますし、後から参画した人にとっても触れづらい領域になってしまいかねないと思うので、EventHubぐらいの規模感であればモノレポで開発できることはメリットだと捉えています。
さいごに
「EventHubの開発やリリースってこんな感じでやってるんだな」というのが良くも悪くも伝わっていれば幸いです。
そして、テックブログ以外にも会社全体の雰囲気を知るためのブログやXもありますので、もし興味を持っていただけたらそちらも是非見てみてください！
TSKaigi 2024では配信プラットフォームとしてEventHubが採用され、弊社CTOの井関がスポンサーLTで登壇したときの動画がありますので、こちらも是非。
