初めに

CI/CD設計で頻出の「semantic release」を理解していきます。先に学ぶべき事項を以下記事にまとめたので併せてどうぞ。

https://zenn.dev/amezousan/scraps/a7ed107c54446a

事前に準備しておくこと

「semantic release」においてcommitメッセージの統一は非常に重要です。チームの方針としてcommitは自由形式で良い、という場合以外は「commitlint + husky」を使うと非常に効果的です。使い方については以下の記事にまとめています。

https://zenn.dev/amezousan/scraps/15688951759a8d

semantic-release のステップ

基本的には以下のステップが実行されます。

上記のステップごとにプラグインが個別に用意されており、それらをもとにリリース作業が行われます。

プラグインの紹介

ちなみに「github上」でもどのプラグインが存在するのかを確認できます。

標準プラグイン

何も設定しなくても入ってるプラグイン達

• @semantic-release/commit-analyzer
  • Major/Minor/Patchのいずれかを決定するためのプラグイン
• @semantic-release/release-notes-generator
  • リリースノートを生成するためのプラグイン
• @semantic-release/npm
  • npmパッケージのバージョン更新やリリースするためのプラグイン
• @semantic-release/github
  • Github Release や Commentを生成するためのプラグイン

オプションプラグイン

追加で利用可能なプラグイン。

• @semantic-release/git
  • リリース作業での変更をgitに反映させるためのプラグイン
• @semantic-release/changelog
  • Changelogの作成、更新
• @semantic-release/exec
  • 任意のコマンドを実行
• @semantic-release/gitlab
  • Gitlab用の@semantic-release/githubパッケージ

プラグインの罠

「semantic-release」が行う以下のステップにおいて各プラグインそれぞれが独自のステップを実行します。その詳細については個別プラグインのGithubページに記載されています。そしてその中でも独自のステップで重複が存在する場合もあるので、不要なステップがないか、よく確認する必要があります。