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)と公式ツールで評価環境を作ってみます。
次の記事も合わせご覧ください。
コメント