エンジニアの皆さん、こんにちは。現場で泥臭いリリース作業に追われ、「毎回CHANGELOGを手動で編集して、GitLabの画面でリリースノートをコピペして…」なんていう不毛な時間を過ごしていませんか？
その手作業、GitLab Release CLIを使えば、今日から「タグを切るだけ」の自動化プロセスに置き換えられます。今回は、GitHub Releasesのような心地よいリリース体験をGitLabで構築するための、「現場で即効性のある」自動化術を伝授します。
—
なぜ「Release CLI」を使うべきなのか？
GitLabのリリース機能は、単なるメモ帳ではありません。バイナリファイルの添付、関連URLの紐付け、そしてGitタグとの強力な連携が可能です。これをCI/CDパイプラインに組み込むことで、「リリース＝リポジトリへのタグ付け」というシンプルな運用が実現します。
手動更新を廃止する最大のメリットは、「リリースノートの書き忘れ」や「タグとリリース内容の乖離」というヒューマンエラーを、パイプラインの力で根絶できる点にあります。
—
1. 準備：CI/CD変数のセットアップ
まず、GitLabがリリースを作成するための権限を持つ必要があります。設定は驚くほど簡単です。
1. プロジェクトの Settings > CI/CD > Variables を開く。
2. `CI_JOB_TOKEN` は標準で提供されますが、より柔軟な制御が必要な場合は、`Project Access Token`（`api` スコープを持つもの）を作成し、`RELEASE_TOKEN` として保存してください。
—
2. 「HelloWorld」的な自動リリースパイプライン
最もシンプルな構成は、`release`ジョブをCI/CDに追加することです。以下の `.gitlab-ci.yml` を見てください。
stages:
- release
create_release:
stage: release
image: registry.gitlab.com/gitlab-org/release-cli:latest
rules:
# タグが作成された時だけ実行する
- if: $CI_COMMIT_TAG
script:
- echo “リリースノートを生成中…”
# ここで直近のコミットメッセージをリリースノートとして抽出
- |
release-cli create \
–name “Release $CI_COMMIT_TAG” \
–tag-name “$CI_COMMIT_TAG” \
–description “
リリース概要
$(git log -1 –pretty=%B)” \
–assets-link “{\”name\”:\”バイナリ\”,\”url\”:\”https://example.com/artifacts/$CI_COMMIT_TAG/bin\”}”
このスクリプトのポイント：
- `image: registry.gitlab.com/gitlab-org/release-cli:latest`: 公式の軽量イメージを使うのが鉄則です。環境構築不要で、即座にCLIが使えます。
- `$CI_COMMIT_TAG`: タグが打たれた瞬間にパイプラインが発火し、そのタグ情報をそのままリリース名に流用します。
- `git log -1`: そのタグでコミットされた内容を自動的にリリースノートの本文として注入しています。
—
3. 高度な運用：CHANGELOGを自動抽出する
現場レベルでは、コミットメッセージをそのまま出すのではなく、特定のフォーマット（例：Keep a Changelog形式）から抽出したい場面が多いはずです。
その場合、スクリプト部を以下のように書き換えるのが「通」のやり方です。
簡易的なCHANGELOG抽出スクリプトの例
- |
# CHANGELOG.mdの最新バージョンセクションのみを抽出するハック
sed -n ‘/
\[$CI_COMMIT_TAG\]/,/##/p’ CHANGELOG.md | sed ‘$d’ > release_notes.txt
release-cli create \
–name “Release $CI_COMMIT_TAG” \
–tag-name “$CI_COMMIT_TAG” \
–description “$(cat release_notes.txt)”
この手法を使えば、開発者は `CHANGELOG.md` を更新してタグを打つだけで、GitLab上のリリースノートが完璧に同期されます。
—
4. 現場で震えるほど役立つ「極限のコツ」
最後に、私が現場で必ず導入している「プラスアルファ」の知恵を共有します。
- パイプラインの依存関係: リリースジョブは、ビルドやテストが全て成功した後に実行されるよう `needs` キーワードで依存関係を定義しましょう。失敗したビルドをリリースしてしまう事故を確実に防げます。
- バイナリの配布: もし成果物がGitLab CIのArtifactsにあるなら、`–assets-link` を工夫して、GitLabのダウンロードURLを直接動的に生成しましょう。これでリリース後の配布作業が0秒になります。
- プレリリースの活用: タグに `-rc` や `-alpha` が含まれる場合は、`release-cli` に `–released-at` や `–description` を微調整することで、開発版リリースと正式リリースを自動判別可能です。
—
まとめ：自動化は「習慣」を変えること
「リリース作業」を儀式にしないでください。GitLabのRelease CLIを導入することで、あなたのチームは「コードを書くこと」と「品質を検証すること」に集中できるようになります。
まずは、小さなプロジェクトの `README.md` を更新し、タグを打って、自分の作成したリリースノートがGitLabに投稿される感動を味わってみてください。一度この快適さを知ってしまえば、もう二度と手動でポチポチとリリースボタンを押す日々には戻れないはずです。
さあ、あなたのCI/CDパイプラインを、最高峰の自動化エンジンへと進化させましょう。応援しています！