semantic-release

semantic-releaseは、次の制約を導入することで、バージョン管理とパッケージ公開を完全に自動化します。

semantic-versioning によるバージョン管理
conventional-commits によるコミットメッセージ形式

次のバージョン番号の決定、リリースノートの生成、パッケージの公開など、パッケージリリースワークフロー全体を自動化することができます。

これにより、semantic-versioningの仕様に厳密に従って、人間の感情とバージョンの間の直接的な関係がなくなります(おそらくルールに従い機械的にバージョンを決定するため、人がバージョンアップする際に次のバージョンで悩んだり、人による曖昧なバージョンの付け方から解放されると理解しました)。

主な特徴
どうやって実現するか？
最後に

主な特徴

完全自動リリース
semantic-versioningを適用する
新機能と修正はユーザーがすぐに利用できる
メンテナとユーザーに新しいリリースを通知する
コミットメッセージ規則を使用して、コードベースの変更を文書化できる
gitマージに基づいてさまざまな配布チャネル（npm dist-tagsなど）で公開する
CIワークフローと統合する
手動リリースに関連する潜在的なエラーを回避する
プラグインを介してパッケージマネージャーと開発言語をサポートする
共有可能な構成によるシンプルで再利用可能な構成

どうやって実現するか？

コミットメッセージの規約

semantic-releaseは、コミットメッセージ形式よってコードベースの変更の種類を判断します。conventional-commitsの規約に従って、自動的に次のバージョン番号を決定し、変更ログを生成し、リリースを公開できるようになります。

Patch Release
e.g.) fix: correct minor typos in code
Feature Release
e.g.) feat: add support for xxx
Breaking Release
e.g.) refactor!: drop support for xxx

CI環境による自動化

semantic-releaseは、リリースブランチでビルドが成功するたびにCI環境で実行されることを目的としています。このようにすることで、人がリリースプロセスに直接関与することはなく、リリースに感情や気持ちが含まれてないことが保証されます。

リリース

リリースブランチ(master、next、betaなど)に新しいコミットが追加されるたびに、git push、pull requestのマージ、他のブランチからのマージによってCI環境のビルドが起動し、semantic-releaseを実行して、パッケージの機能に影響を与えるようなコードベースの変更が前回のリリースからあった場合にリリースを行います。

semantic-releaseでは、公開されたリリースのタイミング、内容、対象者をコントロールするさまざまな方法を提供しています。次のレシピでワークフローの例をご覧ください。

リリース手順

テストを実行した後、semantic-releaseは次の手順を実行します。

Verify Conditions
リリースに必要な条件がすべて揃っているか検証する
Get last release
Gitタグから前回リリースしたバージョンを取得する
Analyze commits
前回のリリースから最新のリリースまでに含まれるコミットを分析する
Verify release
リリース可能な状態か検証する
Generate notes
前回のリリースから最新のリリースまでに含まれるコミットからリリースノートを生成する
Create Git tag
新しいリリースバージョンのGitタグを作成する
Prepare
リリースの準備
Publish
リリースの公開
Notify
新しいリリースまたはエラーの通知

要件

semantic-releaseを使用するには、次のものが必要です。

コードはGitリポジトリに格納すること
認証情報を安全に設定できるCI環境を使用すること
CI環境にGit CLI v2.7.1以降がインストールされていること
CI環境にNode.js v10.18以降がインストールされていること(公式ツールを利用する場合だと思う)

最後に

公式ドキュメントの内容に従ってsemantic-releaseの概要について書きましたが、上手く導入できればソフトウェアのリリース作業を省力化できそうです。ただし、制約が多くなるため、チームによる開発時は学習コストやレビューの負担が大きくなりそうな点、またうまく運用しないとリリースが多くなる可能性があります(人がリリースに介入しようとすること自体がsemantic-releaseと相反するところでもあり、トレードオフの関係になるところでしょうか)。

実際に使っていかないと分からない点もあるので、GitHub(Repository、Actions、Packages)と公式ツールで評価環境を作ってみます。

次の記事も合わせご覧ください。