semantic-release

ソフトウェア公開

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

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

これにより、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)と公式ツールで評価環境を作ってみます。

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

コメント