はじめに
今回はその最終回として「ログ＆バージョニングを管理する」について書きたいと思います。
開催した＆今回記載する内容
- コミットメッセージを統一する ←前々回の記事
- コミットメッセージをチェックする ←前回の記事
- ログ＆バージョニングを管理する ←今回はこれ
ログ＆バージョニングを管理する目的
ソース変更とバージョンを一致させる
バージョン番号(「x.y.z」)には正しく意味があり、大まかには下記となります。
- x：大きな影響を及ぼす変化(見た目が大幅に変わる、前と互換性のない変更 etc.)
- y：機能や情報の追加など
- z：既存機能に影響のない、細かい修正(バグや誤字脱字の修正など)
ソースに対する変更を行う際に、バージョン番号も変更内容に応じた正しい番号にアップする必要があります。
たとえば、バグ修正しかしていないのにメジャーバージョンが上がったりとか、そういうことがないようにする必要があります。
バージョンごとの変更内容を明確にする
バージョンアップは何かしらの変更で行われるので、各バージョンごとに「このバージョンではどんな変更があったか」を明確にする必要があります。
それを行うことでソフトの利用者/開発者に情報を提供することができます。(機能の追加、バグ修正、脆弱性対応状況など)
ツールの紹介
といっても、これらを人力で管理するのは大変なので、これらをサポートしてくれるツールを紹介します。
semantic-release(https://github.com/semantic-release/semantic-release)
- 上記のログ＆バージョニングを行ってくれるツール
- コミットメッセージから判断し、バージョニングやログを記録してくれる
- リモートブランチで動作する
standard-version(https://github.com/conventional-changelog/standard-version)
- こちらも上記のログ＆バージョニングを行ってくれるツール
- 基本的な部分はsemantic-releaseと同じ
- こちらはローカルブランチで動作する
以後、standard-versionを例に説明を行っていきます。(semantic-releaseをしっかり使ったことないので)
参考サイト
- standard-version公式サイト
- standard-version と commitlint で npm パッケージのリリース管理を省力化する - 30歳からのプログラミング
- standard-versionとgit-czを使って、CHANGELOGやバージョンを日本語で管理しよう！
基本的な動き
インストール＆設定
公式サイトの通りに行えばOKです。
# インストール > npm i --save-dev standard-version # npm > yarn add --dev standard-version # yarn
// package.jsonに下記を追加 { "version": "1.0.0", "scripts": { "release": "standard-version" } }
最初のリリース
とりあえず、下記メッセージでcommitを行います
feat(xxx): 検索機能を追加
で、下記コマンドでstandard-versionを実行します。
> yarn release --first-release
すると、以下のことが行われます。
- CHANGELOG.mdの生成＆バージョン番号・commitメッセージの記載
- 上記変更のcommit
- Gitタグ「v1.0.0」の生成
2回目以降のリリース
さらに下記commit＆standard-version実行をします。
> git commit -m "feat(xxx): 部分一致検索を追加" > yarn release > git commit -m "fix(xxx): スペースが入るとエラーになるバグを修正" > yarn release
すると、下記の変更がなされると思います。
- package.jsonのバージョンが「1.1.1」になる
- CHANGELOG.mdにバージョン番号・commitメッセージが追記
- 上記変更のcommit
- Gitタグ「v1.1.0」及び「1.1.1」の生成
まとめると、standard-versionは以下のことを行ってくれます。
- packae.jsonのverison管理(=commitメッセージの内容に応じたバージョンアップ)
- 初回リリース(--first-release)時を除く
- CHANGELOG.mdの作成＆記載
- バージョン番号＆それに対応する変更内容の記載
- 上記変更(package.jsonとCHANGELOG.md)のcommit
- バージョン番号がついたgitタグの作成
バージョンアップのルール
バージョンアップの基本的ルールは「ログ＆バージョニングを管理する目的」に書きましたが、前回＆前々回で紹介したConventional Commitsのページにも記載されています。
standard-versionではConventional Commitsのルールをベースに、下記のルールでバージョンアップが行われるようです。
| type(変更種別) | バージョンアップの種別 | 例 |
|---|---|---|
| fix(バグ修正) | パッチバージョンアップ | v1.0.0→v1.0.1 |
| feat(機能追加) | マイナーバージョンアップ | v1.0.0→v1.1.0 |
| breaking change(破壊的変更) | メジャーバージョンアップ | v1.0.0→v2.0.0 |
| 上記以外 | パッチバージョンアップ | v1.0.0→v1.0.1 |
設定のカスタマイズ
standard-versionのカスタマイズですが、プロジェクトルートに.versionrcファイルを作成し(.versionrc.json, .versionrc.jsでもOK)、そこに設定を定義することで行えます。
設定項目はたくさんありますが、とりあえず最低限だけ紹介します。(あとは公式サイトや--helpオプションの結果を参照)
{ "types": [ // type: 変更種類(feat, fixなど) // section: CHANGELOG.mdのcommitメッセージ前に // 記載する内容(hidden=falseの場合のみ) // hidden: trueの場合、そのtypeのcommitメッセージはCHANGELOG.mdに記載しない。 // (ただしバージョン番号はhiddenの設定に関わらず記載される) {"type": "feat", "section": "Features"}, {"type": "fix", "section": "Bug Fixes"}, {"type": "chore", "hidden": true}, {"type": "docs", "hidden": true}, {"type": "style", "hidden": true}, {"type": "refactor", "hidden": true}, {"type": "perf", "hidden": true}, {"type": "test", "hidden": true} ], "tag-prefix": "xxx-v" "releaseCommitMessageFormat": "chore(release): {{currentTag}}" }
それぞれ、下記の内容です
| 項目 | 説明 | 備考 |
|---|---|---|
| types | 変更種類ごとのCHANGELOG.mdへの記載の設定 | 詳細は「typesの設定」を参照 |
| tag-prefix | gitタグのバージョン番号の前につくプレフィックス | 上記の例だと、例えばxxx-v1.1.0みたいなタグになる |
| releaseCommitMessageFormat | project.jsonやCHANGELOG.mdの更新commitに対して付けられるコミットメッセージ。 | {{currentTag}}は、現在のgitタグ(=バージョン番号)。 詳細は下記URL参照。 |
typesの設定
| 項目 | 説明 | 備考 |
|---|---|---|
| type | 変更種類(feat, fixなど) | |
| section | CHANGELOG.mdのcommitメッセージ前に記載する内容 | hidden=falseの場合のみ有効 |
| hidden | CHANGELOG.mdにcommitメッセージを記載するかどうか。(trueだと記載されない) | あくまで書かれないのはcommitメッセージのみで、バージョン番号はhiddenの設定に関わらず記載される |
コマンドオプション
satndard-version実行時に使用できるオプションになります。(これも主要そうなもののみ記載)
※--first-releaseは説明済なので省略
| オプション | 説明 | 備考 |
|---|---|---|
| --prerelease [name] | プレリリース版としてバージョニングを行う | v1.0.0-[name]のようなバージョンが付与される。 nameは省略可能。省略すると0, 1, 2...とインクリメントする |
| -t <tag-prefix> | gitタグのバージョン番号の前につくプレフィックスを指定する | .versionrcのtag-prefixと同じ |
| --release-as <versionNo> | バージョン番号を直接指定する | |
| --no-verify | project.jsonやCHANGELOG.mdの更新commit時に、Git Hooksを無効にする | 前々回紹介したような、「(git-czなどの)ツールでのcommit以外はエラーにする」ような処理をpre-commitなどでかけている場合に、それを無効にできる |
| --dry-run | 実際にログ記載＆バージョン変更は行わず「もし行ったらこうなる」という結果のみ表示する | 事前の動作確認用 |
まとめ
以上、ログ＆バージョニングを管理する方法でした。
前々回・前回含めてGitのコミットメッセージ管理やそれに伴うログ・バージョン管理を書きましたが、チームの運用管理面でも、こういう点をやっておくとプロダクト管理が非常にやりやすくなると思います。(特に時間が経ってから見返すとき)
また、こういう点は手作業で管理すると大変なので、各種ツールを使って自動化して、なるべくメンバーが本来行うべき作業に工数をたくさん割けるようにしたいものです。
それでは、今回はこの辺で。
