Posted inDevOps

手動のバージョニングを卒業：Semantic Releaseでリリース作業を自動化する

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

手動リリースの苦労 vs. 自動化の快適さ

誰もが経験したことがあるでしょう。金曜日の午後、Gitログを凝視しながら、最後の10個のコミットがマイナーアップデートなのかパッチアップデートなのかを判断しようとしている姿を。典型的な手動ワークフローでは、開発者が手作業でpackage.jsonを更新し、CHANGELOG.mdを書き、タグをプッシュします。このプロセスは人為的ミスの温床です。メモ内のバグ修正を一つ書き漏らしたり、バージョンの繰り上げを忘れたりするだけで、ダウンストリームの依存関係が壊れたり、ユーザーを混乱させたりする可能性があります。

自動化はこの状況を一変させます。推測に頼るのではなく、ツールがコミット履歴を分析して、セマンティックバージョニング（SemVer）に基づいた次の論理的なステップを決定します。最近のプロジェクトで、私たちのチームはこのモデルに移行し、リリースのオーバーヘッドを20分間の手動調整からゼロに短縮しました。システムはただ正常に動作し、リリースは退屈なほど予測可能になります。それこそがあるべき姿なのです。

真の変化は、信頼できる情報源（Source of Truth）を開発者の記憶からコードそのものへと移すことにあります。コミットメッセージが標準に従っていれば、リリースは作業の自然な副産物となります。「リリース作業をする」のをやめ、ただ「コードを届ける」ようになるのです。

Semantic Releaseはあなたのチームに適しているか？

導入にあたっては、即座に得られるメリットと、システムを維持するために必要な規律を天秤にかける必要があります。

メリット

  • タッチレスな一貫性： すべてのリリースが数学的な論理に従います。バージョン番号を誤って飛ばしてしまうことは二度とありません。
  • 即時の変更履歴作成： ツールがCHANGELOG.mdを自動生成します。新機能、修正、破壊的変更をユーザーのために分かりやすくカテゴリ分けしてくれます。
  • クリーンなGit履歴： チームに意味のあるコミットメッセージを書くことを強制します。「fixed stuff（いろいろ修正）」や「updated CSS（CSSを更新）」といったコミットはもう不要です。
  • 開発者の集中： プルリクエストがマージされれば、開発者の仕事は終わりです。あとはCI/CDがすべて処理します。

注意点

  • 厳格な標準： すべてのコントリビューターがConventional Commitsの仕様に従う必要があります。fix: ...の代わりに「hotfix」のような勝手なコミットを一つでも混ぜると、パイプラインが停止することがあります。
  • 事前の設定： 最初のリリースまでに、GitHubのシークレット設定やCIの権限設定に30分ほど時間をかける必要があります。

プロフェッショナルなパイプラインの設計図

堅牢なワークフローを構築するために、最新のDevOpsツールと相性の良いスタックを推奨します。たとえJavaScriptを使用していなくても、この Nodeベースのツールはリリース自動化の業界標準です：

  • Conventional Commits： 自動化ツールが理解する言語（例：feat:、fix:）。
  • GitHub Actions： リリーススクリプトを実行するエンジン。
  • 主要なプラグイン：
    • commit-analyzer: バージョンの繰り上げが必要かどうかを判断します。
    • release-notes-generator: 人間が読める形式のサマリーを下書きします。
    • changelog: 実際のCHANGELOG.mdファイルを更新します。
    • git: 更新されたバージョンと変更履歴をリポジトリにプッシュバックします。

ステップバイステップの導入手順

プロジェクトにゼロから組み込む方法は以下の通りです。

ステップ1：ツールキットのインストール

コアパッケージと主要なプラグインを開発用依存関係（devDependencies）に追加します。

npm install --save-dev semantic-release @semantic-release/changelog @semantic-release/git @semantic-release/github

ステップ2：リリースロジックの設定

ルートフォルダに.releasercファイルを作成します。このファイルはリリースプロセスの「頭脳」として機能し、mainブランチにマージされたときに何が起こるかを正確に定義します。

{
  "branches": ["main"],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    [
      "@semantic-release/changelog",
      { "changelogFile": "CHANGELOG.md" }
    ],
    "@semantic-release/npm",
    [
      "@semantic-release/git",
      {
        "assets": ["package.json", "CHANGELOG.md"],
        "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
      }
    ],
    "@semantic-release/github"
  ]
}

[skip ci]タグは非常に重要です。これは、ボットがバージョン更新をプッシュしたときにGitHub Actionsが新しいビルドを開始しないように指示し、無限ループを防ぐためのものです。

ステップ3：コミット言語をマスターする

バージョニングは、コミットメッセージの書き方に依存するようになります。実際には次のように計算されます：

  • fix: メモリリークを解消 -> Patch (v1.0.0 から v1.0.1)
  • feat: Google OAuthログインを追加 -> Minor (v1.0.1 から v1.1.0)
  • feat!: Node 14のサポートを終了 -> Major (v1.1.0 から v2.0.0)

ステップ4：GitHub Actionsで自動化する

.github/workflows/release.ymlを作成します。このスクリプトは、mainブランチにプッシュするたびにリリースをトリガーします。ツールが履歴全体を参照できるように、fetch-depth: 0を設定してください。

name: リリース
on:
  push:
    branches: [main]

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      issues: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: "lts/*"
      - run: npm install
      - env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: npx semantic-release

ステップ5：検証と開始

feat:で始まるコミットをプッシュして、「Actions」タブを確認してください。ボットがコミットを分析し、リポジトリにタグを付け、GitHub Releaseを生成するのが確認できるはずです。私の経験では、最初の設定には30分かかりますが、1週間以内にその分の元は取れます。人的要素を排除することで、バージョニングが数学的に正しく行われ、ユーザーは何が変更されたかを常に正確に知ることができるようになります。

Share:
Tags: