BaaSなプロジェクトにtagprを導入してみた
はじめに
tagprが100 stars超えされていました。おめでとうございます！
tagprは、とあるOSSのリポジトリで導入されて体験する機会がありました。
開発者体験が頗る良く感動し、今絶賛開発中のBaaSの開発プロジェクトに導入した件についてまとめたいと思います。
tagprを知るきっかけを作って頂いたOSS開発での内容については @k1LoW さんがまとめてくれています。
導入したプロジェクトについて
スキーマ駆動開発を採用しているBaaSプロジェクトになります。 [1]
こちらのサービスが提供するAPIは複数クライアント（サービス）から利用されます。
複数の組織が管理するサービスからアクセスしてもらうことを想定しています。
マルチテナントなサービスとして開発を進めていますが、扱うデータと各クライアントのサービスの特性から複数環境にリリースを行います。
ざっくり纏めると以下の様になると思います。
- BaaSの接続クライアント向けにスキーマ（OpenAPI Spec）を先行公開して並行開発する
- 複数環境に複数のバージョンが稼働する
各サービス毎に提供するAPIは同じですが、クライアントとバージョンアップのタイミングを合わせる必要があり、完全にバージョンを統一できない [2] - リリース前には必ずQAテストを実施し、リリースサイクルは比較的長く月単位
バージョニングが必要なプロジェクトになりますが、QAテストが入る点と、リリースサイクルが長いのが特徴的でしょうか。
バージョニングにおける課題感
以下の課題感がありました。
- 複数クライアント（サービス）と並行開発するのでAPIのバージョンを明確化したい
普段の開発サイクルでも細かくバージョニングして関連するチーム間での認識するバージョンの齟齬をなくしたい - 他部署の開発者へのAPIの変更有無及びその内容を確実に伝えたい
- チーム開発環境 -> QA環境 -> 本番環境と統一したリリースフローを作りたい
deployタイミングでバージョンの不整合を防ぎたい - チーム内でリリースタイミングでのmigrationの統合やI/F変更の調整を行いたい
上記の課題に対しては細かくバージョニングを行う必要がありますが、開発負荷が高くなる懸念がありました。
tagpr導入前までの開発イメージ
他のプロジェクトでは、本番リリース前だけtag付けのみを行うリリースフローで運用されていました。
- 本番環境以外へのdeployはdevelopブランチをリリースするだけ
- tag付け作業を行うメンバーも限られていた
バージョンの齟齬が発生しやすい開発フローでした。
BaaSの開発をスタートしてからも、上記と同じくチーム開発環境へのリリースはdevelopブランチのみで行っていました。
リリース内容の全体把握が出来ているのは自分のみだったので、一人で作業を行っており、気分次第でリリースしたり、しなかったりという感じです。
リリース時の各クライアントのチーム向けへの共有ですが
- APIの変更点をリリース前に事前告知のみ
- 細かい内容までは伝え漏れている
- そもそもリリース後のアナウンスが忘れられていたり
といった状況でした。
また開発段階でdeplooyスクリプトの整備が追いついていなかったりで、migrationの適用漏れも発生していたりしました。
tagpr導入後の開発手順
まだ試行錯誤の部分もありますが、tagpr後は以下の運用ルールとしました。
- 開発環境へのリリースは、かならずリリースPRをmergeしてから行うフローとする
- リリース後は各チームにReleaseノートのURLを共有する
- OpenAPIのSpecに記載するバージョンを連動させる用にtagprへ設定を入れる
- Breaking ChangesなAPIの変更があるPRはminorラベルをつける
- ReleaseノートにAPIの変更点を追記する
- migrationやライブラリアップデートがあるPRはminoラベルをつける
- 本番リリース時にはmajorラベルをつける（予定）
あと細かい所ですが、リリース作業手順をまとめてチーム内外への共有を行いました。
作業手順と各クライアントのチームへの共有ルールはpatchバージョンとそれ以外とでフローを分けるようにしました。
tagpr導入で実現できたこと
- バージョンアップの共有はReleaseノートのURLを共有するだけで良くなった
- 環境毎にどの時点でのバージョンが反映されているか？わかりやすくなった
- 開発環境以降のリリース作業を各サービスの開発担当者へ任せられるようになった
- OpenAPI SpecのI/F上のバージョンと検証時のバージョンの整合性を把握できる様になった
- リリースの一連の作業をメンバーに任せられるようになった
これらのことが、それほど運用負荷をかけずに実現できました。
1についてはtagprが自動でPRの一覧をReleaseノートにまとめてくれるのでAPIの変更点がなければ手を入れずに共有するだけで済みます。本当に楽でありがたいです！
少し要望を上げるならば、PRについていたラベルも一緒にReleaseノートへ出力できると他の開発者の関心がありそうなPRを把握しやすくて良さそうと思いました。[3]
2〜4についてはスキーマ駆動開発で並行開発をしていく中で、安心感が全然違うと感じました。これは対外でだけでなく、チーム内でも今どのバージョンが反映されていて、次に何をリリースするのか？というのが明確になるのが大きいと感じています。
個人的にはReleaseノートだけでなく、リリースPR自体を次のバージョンアップの予告に使える様になったのも嬉しかったです。
あとリリースPRの変更点が積み上がってくると、早めにリリースしようという気にもなってきますｗ
最後の5についてですが、リリースフローが明確になって簡単に誰でもリリースができる様になったのが大きいです。機能毎にチーム分けして開発していると、全体を把握しているリーダーが細々したリリースの段取りだったり調整を行うことが多い印象でしたが、リリース内容を全員が把握しやすくなったので細かい指示を出さなくても自主的に調整を行える様になったと思います。
開発の初期段階では頻繁にmigrationの見直しが入りますが、リリース前であればmigrationを統合させるといったこともメンバー主導で行うことができる様になります。
リリース全体のマネジメントコストが下げられて、一人でリリースのお守りしていた負担 [4]が分散されて心理的な負担も軽くなったと感じました。
今後の課題について
導入したプロジェクトですが、まだ絶賛開発中で1stリリースはこれからとなります。
これから発生するであろう以下のユースケースをどうするか？については検討中です。
- QAテストが完了した後にリリース(major)のバージョンを上げる
- 本番リリース後のHotfixリリース
プロジェクト的にはminorとpatchは開発バージョン、majorはリリースバージョンとして扱うのが良さそうだと考えています。
普段はpatchやminorのバージョンアップを繰り返し、QAテストが完了してリリースがreadyになったらmajorバージョンを上げたいです。
現状のtagprでは releaseBranch に変更がないとリリースPRが作られない為、手動でリリースPRを作るか？リリースPRを作成するコミットを入れる感じになりそうです。
tagprのGitHub Actionsを workflow_dispatch からバージョン指定してリリースPRが生成できると、一手間省けて良さそうです。
2のユースケースついては、色々悩ましいです。
リリース後に開発（releaseBranch）が進んでいるケースがあるので。。
releaseBranch に既に反映されているものがpatchレベルなら、通常通りに修正PRをmergeしてバージョンを上げてしまえばよいのですが、 minorが上がってしまっている場合は別フローを考えないといけません。
tagpr外のフローでバージョン管理をしてしまえば良いと思うのですが、デプロイ周りのCIフローをtagprと連動させる形で構築している場合にはもう少し考える必要がありそうです。
HotfixのPR自体をtagprのリリースPRの形式に合わせて作成してあげれば良さそうですが、まだ検証できていません。
理想ですが、Hotfix用のリリースブランチにmergeされたらcommitツリー上の直近のmajorバージョンに対してリリースが切れる様になるといいのですが。。
以下は完全に妄想なブランチワークとなります。
もっと良いアイデアがあれば、アドバイスを頂けると大変助かります mm
最後に
スキーマ駆動開発のバージョニングを行うにはtagprはすごいマッチすると思います。
実際に導入してみて本当に心地よいリリースマネジメントが出来るようになったと感じています。
tagprがなかったら細かくバージョニングを行うというマインドにはならなかったと思います。
tagprはツールですが、リリースの運用もスッキリし、プロジェクトの文化にも良い影響を与えてくれるのでは？と期待しています。
まだまだ手探りな部分がありますが、プロジェクトに沿ったいい感じになる様に開発サイクルに組み込んでいきたいと思います。
Discussion