Web Developer の @yuya-takeyama です。
入社から 1 年と少し経ちました。
Quipper School/スタディサプリ高校講座/大学受験講座の Web 開発を担当していて、帰宅前にバッティングセンターに通うのがほぼ日課です。
今日はリリースに関する話を書きますが、デプロイの自動化とかそういった話ではなく、もうちょっと泥臭い話です。
リリースまでの流れ
前提として、Quipper では本番環境へのアプリの自動デプロイはあまり行っていません。 カスタマーサポート用の社内アプリ等は GitHub での master ブランチへのマージ時に自動デプロイを行っていたりもしますが、 エンドユーザ向けのアプリは週に一度、以下のような流れで行います。
- その週のリリースに必要な機能が揃ったところでリリース用のブランチを作成し、リリーステスト用の環境にデプロイ
- テストケースに沿ったテストを人力で実行
- 問題があった場合は修正用の Pull Request を cherry-pick して再度確認
- 問題なくテストが完了したら Jenkins で本番環境にデプロイ
本当はもっと複雑ですが、それについては後述します。
ところでちょっと話はそれますが、人力のテストはやはり辛いよね、という話はずっとあって、私の入社前には E2E テストが行われていたそうなんですが、 Quipper のプロダクトは基本的にゴリゴリの Single Page Application であり、複数のアプリをまたぐ必要 (先生として宿題をだし、それを生徒として解いたり) もあったりして、 メンテナンスが困難だったため、現在は一旦人力でのテストに落ち着いています。 (ちょうど今、E2E テストを再び、ということで絶賛稼働中のプロジェクトもあるので、その辺の話もいずれこのブログで紹介できるかもしれません) (あと、言うまでもないですが、モデルやコンポーネント単位の Unit Test や、アプリをまたがない Feature Test はしっかり書いています)
人力でのテストはプロダクトチームだけでなく Biz や HR のメンバーも巻き込んで行っています。 長永 @kyanny のブログがより詳しいです。
Quipper におけるリリースの特殊な点
Quipper では現在、Quipper School/Quipper Video をグローバルに、スタディサプリ高校講座/大学受験講座を日本国内に向けて展開しています。 デプロイ時のフラグによってスキンを変えていたり、細かい機能の出しわけはあるものの、基本的にソースはひとつです。 (アプリやリポジトリ自体は生徒向け・先生向け・コンテンツ制作者向けのもの等で分かれています)
ひとつのソースをフラグで切り替えて複数デプロイ、というところに危険信号を感じている方もいるかもしれません。 ここはもちろん苦労もありますが、「Quipper というグローバルプラットフォームを作る」という Quipper の思想的なところとも関係しています。 また、そうは言っても両者で大幅に違うことをやっているわけではなく、個別機能の出しわけ程度に留めていることもあって、現状はしっかりメリットを実感できています。 これでうまく運用するための仕組みも色々とあるので、それについてはいずれ別の記事で紹介できればと思っています。
先ほどは端折りましたが、グローバル/国内両方のリリースを含めると以下のようになります。
- 普段はトピックブランチで開発し、レビュー後に
developブランチにマージ - グローバルのリリースに向けて
releaseブランチを作成、リリーステストを行う - テスト完了後に
masterブランチにマージして Quipper School/Quipper Video の本番環境にデプロイ - 翌日、
masterブランチからスタディサプリのリリース用のブランチ (仮にrelease-sapuriとする) を作成し、リリーステストを行う - テスト完了後にスタディサプリの本番環境にデプロイ
なかなか複雑な感じですね。
さらに、グローバルのリリースには間に合わなかったけどスタディサプリのリリースには入れたい機能を release-sapuri ブランチに cherry-pick する、という作業が発生することもままあります。
また、これらのリリースの作業については、スタディサプリはビジネスサイドとの調整等も考慮して東京オフィスのメンバーを中心に、 Quipper School/Quipper Video についてはそれ以外のオフィスでローテーションで実行しています。 分担しているとはいっても、スタディサプリのリリースは Quipper School/Quipper Video のリリースに依存していますし、そもそもソースは同一なこともあって両者の密な連携が必須です。
リリース番長
面倒そうなアレコレを整理すると、すでにこれだけのものが挙がっています。
- リリースに必要な機能の確認
- それらの機能の進捗の確認
release-sapuriブランチへのcherry-pick- リリーステスト中に行った修正の
cherry-pick - リリース環境・本番環境へのデプロイ
当初は特に担当を決めずにいましたが、比較的在籍期間の長いメンバーを中心に負荷が偏りがちになってしまったので、それを分散するべく作った役割がリリース番長です。
リリース番長は上記のような作業をはじめとし、リリースがスムーズに行われるためのあらゆることを行います。 バグ報告が上がった時の最初のレスポンスや、修正作業の振り分け、またはテスト実行中のトラブル (テスト用の端末が見つからない、とか) の解決なんかも行います。 そしてリリース番長はリリースごとに Web Developer 内でローテーションします。
以前はリリーステストの開始時刻も予定より遅れがちで、結果として終了時間も引きずられていましたが、リリース番長ができてからは比較的スムーズに進められるようになっています。
また、これはもともとスタディサプリのリリースのために東京オフィスのみでの取り組みでしたが、最近グローバルのリリースについても同じ仕組みをバックポートしました。 そちらは元々 Release Manager がいたものの、ローテーションではなかったので負荷が集中しがちな問題がありましたが、それにより改善しています。
マイルストーンの管理
リリースに関する雑務的な問題はリリース番長によってある程度解決されました。 ですが、プロダクトが拡大し続け、関係者も増える中で「リリースに必要な機能」「それらの進捗」といった情報のやりとりについては煩雑になりがちです。
その問題を解決するために使っているのが、GitHub Issues の Milestone 機能です。 マイルストーンと言っても、プロダクトロードマップに沿ったような何かとかではなく、ここでは単に「どの週にどの機能をリリースするか」の管理だけに使っています。 これを使えば、リリース番長がすべきは以下だけとなります。
- リリース日が近づいたら Slack でマイルストーンの設定を行うよう促す
- その週がマイルストーンとなっている Issue の一覧を確認する
- その中で完了していない Issue があったら担当者に進捗を確認したり、場合によっては翌週以降にずらすことを提案したりする
これであれば、情報の収集に必要な労力はほとんど問題ないレベルです。 また、マイルストーンは誰でも簡単に確認できるので、例えばリリース番長が急に病欠したとしてもすぐに代役を立てられるようになっています。
ラベルやマイルストーンの運用については、以前本多 @hakobera が書いた以下の記事とそんなに変わりませんが、SPoF を生まないようになっているのはチームの拡大に沿った進化だと言えるでしょう。
これについても東京オフィスでのスタディサプリのリリースでうまくまわり出したので、グローバルのリリースに対してフィードバックを行っています。
いろいろ議論した結果、スタディサプリが Issue への Milestone で管理にするのに対し、グローバルでは Pull Request に Release というラベルを貼る運用をすることになりました。
Issue への Milestone だと、どの週に何をやったかとか、週ごとのリリース Issue の量とかを後からでも追いかけやすい一方、週ごとの Milestone を作るのが面倒といえば面倒です。
一方、Release タグだけでの運用だと、後から細かいトラッキングはしにくいものの、いちいちラベルを作らなくて済むし、リポジトリをまたいで一元管理も可能です。
(Quipper では Issue は基本的に全て Issue 専用のリポジトリに集約して運用している)
どちらが良いかは実際にやってみて検討しよう、という状態で、メリットが明確ならサクッと合意を取ってアクションに移し、その結果から素早く次のアクションに繋げる、というのはなんとも Quipper らしいと思います。
現在残る課題
リリース作業の運用についてはなかなかこなれてきた感がありますが、まだまだ以下のような課題があります。
- リリーステストの負荷が大きい
- 先に書いた通り、E2E テストの実装を進めてはいるものの、どこまで自動化すべきか、といったさじ加減など、絶対的な正解はなさそうです
- リリーステストで発覚する不具合が多い
- 不具合を見つけるためにやっているので、それはそれでワークしていると言えなくもないものの、できれば Pull Request の時点でのレビューで何とかしたいところです
- Quipper School/Quipper Video のテストは通ったのにスタディサプリではエラーになる、ということもときどき起こっています
まとめ
Quipper のリリースにはチームがグローバルであること・展開する市場が複数あることによる大変さもありますが、 フラットかつオープンなコミュニケーションという Quipper らしさをもって、プロダクトチームで一体となって問題を解決していっています。 また、オフィス内だけでなく、他国のメンバーも巻き込んで議論し、プロセスを改善していけるのも Quipper での楽しみの一つです。
一方で、よりプロダクトの品質に直結する部分での課題もまだまだ残っており、そういった点も含めて一緒に開発してくれるメンバーを絶賛募集中です。
★Quipper日本オフィスでは仲間を募集しています。是非お気軽にご応募ください。★
