セマンティックリリースによるプレリリースの公開 について動作確認してみました。元ネタはPre-releasesです。
将来のリリースを開発する中でバージョンの不要なインクリメントを回避し、ベータ版としてリリースします。
前提/制約条件
- 最新バージョンのチャネルは@latest(branch: main or master)、プレリリースのチャンネルは@beta(branch: beta), @alpha(branch: alpha)とします
- 次の環境で動作確認します
- GitHub Repository(ソースコードのリポジトリ)
- GitHub Actions(CI環境、この環境でsemantic-releaseを実行する)
- GitHub Releases(変更履歴)
- GitHub Packages(NPMレジストリ)
動作確認手順
元ネタの使用例の手順にそって動作確認します。
- 初回リリース
feat: initial commit => v1.0.0 on @latest
プロジェクトの初回コミットを行うところから始めます。 - 将来のリリース作業の開始
feat: first feature \n\n BREAKING CHANGE: it breaks somethings => v2.0.0-beta.1 on @beta
複数の新機能で構成される将来のメジャーバージョンの開発に取り組むことを決定しました。その一部には破壊的な変更が含まれます。テスト目的で開発された新機能毎にリリースしたいのですが、すべての機能の開発が完了するまで、リリース毎にバージョンをインクリメントしたり、開発が完了するまでユーザーに公開できないようなことは避けたいと考えています。
これを実現するためにv1.0.0からbetaブランチを作成し、そこで開発を行います。このブランチのコミットをプッシュするとsemantic-releaseはプレリリースバージョン 2.0.0-beta.1を@betaに公開します。
feat: second feature => v2.0.0-beta.2 on @beta
@betaで他の機能やバグ修正をコミットしてプッシュすることで、作業を継続することができます。プッシュするたびにsemantic-releaseは新しいプレリリースを@betaに公開します。 - @latestでのバグ修正のリリース
fix: a fix => v1.0.1 on @latest
将来のリリース作業を行っている間も、@latestに変更をコミットし、リリースすることもできます。 - 新な将来のリリース作業の開始
feat: first feature of other release \n\n BREAKING CHANGE: it breaks somethings => v3.0.0-alpha.1 on @alpha
ベータ版と並行して、別の将来のメジャーバージョンの開発に取り組むことを決定しました。
これを実現するためにbetaブランチからalphaブランチを作成し、そこで開発を行います。このブランチのコミットをプッシュするとsemantic-releaseはプレリリースバージョン 3.0.0-alpha.1を@alphaに公開します。
feat: second feature => v2.0.0-alpha.2 on @alpha
@alphaで他の機能やバグ修正をコミットしてプッシュすることで、作業を継続することができます。プッシュするたびにsemantic-releaseは新しいプレリリースを@alphaに公開します。 - @betaを@latestとして公開する
Merge branch beta to master => v2.0.0 on @latest
@betaで開発した機能が完成したので、@latestとしてリリースします。@betaを@latestにマージしてプッシュすることで、v2.0.0をリリースします。 - アルファ版をベータ版に昇格させて公開する
Merge branch alpha to beta => v3.0.0-beta.1 on @beta
@betaで開発していた機能は@latestにマージされリリースしたので、アルファ版をベータ版に昇格させることにしました。@alphaを@betaにマージしてプッシュすることで、v3.0.0-beta.1をリリースします。 - @betaを@latestとして公開する
Merge branch beta to master => v3.0.0 on @latest
ベータ版に昇格した機能が完成したので、@latestとしてリリースします。@betaを@latestにマージしてプッシュすることで、v3.0.0をリリースします。 - 更なる将来のリリース作業の開始
Merge branch master into beta
feat: new feature => v3.1.0-beta.1 on @beta
引き続き、将来の開発を継続するためには、@latestの変更を@betaにマージする必要があります。
動作確認結果
| 手順 | @latest | @beta | @alpha |
| (1) | v1.0.0 TAG: 作成 RELEASES: 作成 PACKAGES: 作成 通知: メール | ||
| (2) | v2.0.0-beta.1 〜 v2.0.0-beta.2[pre-release] TAG: 作成 RELEASES: 作成 PACKAGES: 作成 通知: メール | ||
| (3) | v1.0.1 TAG: 作成 RELEASES: 作成 PACKAGES: 作成 通知: メール | ||
| (4) | v3.0.0-alpha.1 〜 v3.0.0-alpha.2[pre-release] TAG: 作成 RELEASES: 作成 PACKAGES: 作成 通知: メール | ||
| (5) | v2.0.0 TAG: 作成 RELEASES: 作成 PACKAGES: 作成 通知: メール | ||
| (6) | v3.0.0-beta.1[pre-release] TAG: 作成 RELEASES: 作成 PACKAGES: 作成 通知: メール | ||
| (7) | v3.0.0 TAG: 作成 RELEASES: 作成 PACKAGES: 作成 通知: メール | ||
| (8) | v3.0.0-beta.1[pre-release] TAG: 作成 RELEASES: 作成 PACKAGES: 作成 通知: メール |
まとめ
@beta, @alphaの変更は、プレリリース番号がインクリメントされ、@latestにマージする際には、1つの変更として認識され、次のバージョンが決定するのが特徴です。
- @beta, @alphaは、変更のプッシュが行われるたびにプレリリース番号がインクリメントされ、リリースされる
- @betaを、@latestにマージする際は、1つの変更として認識され、次のバージョンを決定する
次の記事も合わせご覧ください。
コメント