tagpr の導入とバージョニングについて

この記事はコネヒトアドベントカレンダー18日目の記事です。
もう来週はクリスマス。アイスケーキが食べたいです🎅

tl;dr

• セマンティックバージョニングを利用してないリポジトリに対して tagpr の導入は現状難しい
• そもそも導入の際にはサービスの特性やリリース周期だったりを踏まえた上で判断した方がいい

はじめに

最近会社のプロダクトに GitHub Actions を導入し、デプロイフローの改善を行なっていました。

GitHub Actions を利用すると、当たり前ですが GitHub との相性もよく、デプロイを行う上でできることの幅が広がります。また、世には多くの便利な actions も OSS として公開されているので、actions を組み合わせることで、よりデプロイを快適なものにできる可能性があります。

今回は GitHub Actions の中でも tagpr という actions を導入しようとした時に、バージョニングについても考える良いきっかけになったので記事にしたいと思います。

tagpr についての説明は著者の方のブログや README を参考にしていただければと思います。
https://github.com/Songmu/tagpr

tagpr の導入

tagpr を導入する際の前提としては リリース時にsemver形式のtagを打つフロー である必要があります。
元々セマンティックバージョニングを採用してる場合は README に書いてあるようにリリースブランチへの push をトリガーとする actions に追加するだけで、既存のバージョンに追従したバージョニングをしてくれます。
下記の例では元々 v0.1.0 が最新だったリポジトリに tagpr を導入すると、自動で v0.1.1 のリリース PR を作成してくれます。

デフォルトではpatchバージョンを上げるようになってますが、メジャーおよびマイナーバージョンを上げる場合はtagpr:major, tagpr:minor といったラベルの付与で指定をするか、versionFile と呼ばれるファイルで直接指定することで意図したバージョン指定をすることができます。

このようにセマンティックバージョニングを採用してる OSS などについては簡単に導入できるため、非常に使いやすい印象を受けました。
また最近 v1.0.0 がリリースされたことで他の actions との連携もやりやすくなったようで、できることが増えていそうです。

途中から導入は可能か？

ではセマンティックバージョニングを採用してなかったリポジトリに途中から導入はできるのでしょうか？
例えばセマンティックバージョニングではなく日付形式(YYYYMMDD.i)を採用していた場合はどんな挙動になるでしょうか？
20221218.1 というタグが存在するリポジトリに tagpr を導入すると Release for v20221218.1.1 という形で YYYYMMDD.i の形式にバージョニングされるようになります。
これを回避する方法があるか内部実装も読んでみたのですが、現状だと最新のタグを取得する処理において、vX.Y.Z形式よりも日付形式のタグが最新として取得できるため、セマンティックバージョニングを採用してないリポジトリに対する途中導入は難しそうでした（元々ブログにsemver前提という記載もあるのでそれはそう）。

そもそものバージョニングについて考える

セマンティックバージョニングを採用してないリポジトリに導入は難しそう、という結論なのですが、そもそも採用してなかったリポジトリについてセマンティックバージョニングに変更するとどうなるのか？という疑問になり、改めてバージョニングについて調べてみました。

セマンティックバージョニングのドキュメントを読むと、仕様書の箇所で下記の記載があります。

セマンティック バージョニングを適用するソフトウェアはパブリックAPIを宣言しなければなりません（MUST）。このAPIはコード自体で表現されているかもしれませんし、明確に文書として存在してるかもしれません。どちらにせよ、正確かつ漏れがないようにするべきです（SHOULD）。

また、バージョニング方法の別形式として、リリース日の日付や時間を組み込んだバージョニングの形式をカレンダーバージョニング(CalVer)と言います。
このCalVerのドキュメントには「いつCalVerを使うか」という箇所に下記のように記載されてます。

・ Does your project feature a large or constantly-changing scope?
・ Is your project time-sensitive in any way? Do other external changes drive new project releases?

これを踏まえると、パブリックな API ではなかったり、変更頻度が高く、他リポジトリへの影響が少ない場合は、カレンダーバージョニングの方を採用する利点もあり、セマンティックバージョニングにすることでかえって制約や複雑さが出てしまうのかもしれないな、と思いました。

まとめ

tagpr の導入からバージョニングについて色々調べるきっかけとなり、改めてバージョン管理について再考するきっかけとなりました。

ただツールとして便利そうだから導入ではなく、導入した後の流れを加味することや、そもそも今の運用フローの意味を踏まえた上での導入検討は改めて大事だな、という学びがありました。

また、バージョニングについては歴史的経緯だったり、各 OSS についても考え方が異なってたりするので、自身がよく使う OSS についてバージョン管理を追ってみると発見があるかもしれません。

話がバージョニングの方に移ってしまいましたが、tagpr はプロジェクトによって有用な場面が多そうなので、導入ができそうなプロジェクトについて積極導入を検討したいと思います！

参考

• ソフトウェアのバージョンと開発スタイルの関係について
  • 各 OSS についての考察が深く、読んでいて学びが多い記事でした
• WHEN TO USE SEMVER OR CALVER: PROJECT TYPE CONSIDERATIONS
  • セマンティックバージョンとカレンダーバージョンの使い所について比較されている記事です