リリース
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
重要なマイルストーンでプロジェクトをパッケージ化するには、リリースを作成します。リリースは、コード、バイナリ、ドキュメント、リリースノートを組み合わせて、プロジェクトの完全なスナップショットを作成します。リリースを作成すると、GitLabは自動的にコードにタグを付けて、スナップショットをアーカイブし、監査に対応したリリースエビデンスを生成します。これにより、コンプライアンス要件に最適な永続的なレコードが作成され、開発プロセスに対するユーザーの信頼を向上させることができます。
ユーザーが得られるメリット:
- 最新の安定バージョンとインストールパッケージへの容易なアクセス
- 新機能と修正に関する明確なドキュメント
- 対応するアセットを含む特定のバージョンをダウンロードする機能
- プロジェクトの経時的な進化を追跡するシンプルな方法
リリースに関連付けられたGitタグを削除すると、リリースも削除されます。
リリースを作成する際、または作成後は、以下を実行できます:
リリースを表示する
リリースのリストを表示するには:
左側のサイドバーでデプロイ > リリースを選択するか、または
プロジェクトの概要ページに少なくとも1つのリリースがある場合は、リリースの数を選択します。
- 公開プロジェクトでは、すべてのユーザーにこの数が表示されます。
- プライベートプロジェクトでは、この数はレポーター以上のロールが付与されたユーザーに表示されます。
リリースを並べ替える
リリース日または作成日でリリースを並べ替えるには、並べ替え順序ドロップダウンリストから選択します。昇順と降順を切り替えるには、Sort order(並べ替え順序)を選択します。
最新リリースへのパーマリンク
最新のリリースページにパーマリンクを使用してアクセスできます。GitLabは常に、パーマリンクURLを最新のリリースページのURLにリダイレクトします。
URLの形式:
https://gitlab.example.com/namespace/project/-/releases/permalink/latestパーマリンクURLには、サフィックスを追加することもできます。最新のリリースがv17.7.0#releaseで、gitlab-orgのネームスペースおよびgitlab-runnerプロジェクトにある場合の読み取り可能なリンクの例は、以下のとおりです:
https://gitlab.com/gitlab-org/gitlab-runner/-/releases/v17.7.0#release以下のパーマリンクを使用して、最新のリリースURLにアクセスできます:
https://gitlab.com/gitlab-org/gitlab-runner/-/releases/permalink/latest#releaseリリースアセットへのパーマリンクの追加の詳細については、最新のリリースアセットへのパーマリンクを参照してください。
並べ替えの設定
GitLabはデフォルトでは、released_at時間を使用してリリースをフェッチします。クエリパラメータ?order_by=released_atの使用はオプションであり、?order_by=semverのサポートはこのイシューで追跡されています。
RSSフィードを使用してリリースを追跡する
GitLabは、プロジェクトのリリースに関するRSSフィードをAtom形式で提供します。フィードを表示する方法は、以下のとおりです:
- メンバーになっているプロジェクトの場合:
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- デプロイ > リリースを選択します。
- すべてのプロジェクトについて:
- Project overview(プロジェクトの概要)ページに移動します。
- 右側のサイドバーで、リリース( )を選択します。
- 右上隅のフィードシンボル( )をクリックします。
リリースを作成する
リリースは、以下のとおり作成できます:
- CI/CDパイプラインのジョブを使用する。
- リリースページで作成する。
- リリースAPIを使用する。
リリースページでリリースを作成する
前提要件:
- プロジェクトのデベロッパー以上のロールが付与されている必要があります。詳細については、リリースの権限を参照してください
リリースページでリリースを作成するには:
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- デプロイ > リリースを選択し、新しいリリースを選択します。
- タグ名ドロップダウンリストから、以下のいずれかを選択します:
- 既存のGitタグを選択します。リリースにすでに関連付けられている既存のタグを選択すると、検証エラーが発生します。
- 新しいGitタグ名を入力します。
- タグを作成ポップオーバーで、新しいタグを作成する際に使用するブランチまたはコミットSHAを選択します。
- オプション。タグメッセージを設定テキストボックスに、注釈付きタグを作成するためのメッセージを入力します。
- 保存をクリックします。
- オプション。リリースに関する以下のような追加情報を入力します:
- リリースを作成を選択します。
CI/CDジョブを使用してリリースを作成する
ジョブ定義でreleaseキーワードを使用すると、GitLab CI/CDパイプラインの一部としてリリースを直接作成できます。CI/CDパイプラインの最後のステップの一環としてリリースを作成する必要がある可能性があります。
リリースが作成されるのは、ジョブがエラーなしで処理された場合のみです。リリース作成中にAPIがエラーを返した場合、リリースジョブは失敗します。
以下のリンクは、CI/CDジョブを使用してリリースを作成するための一般的な設定例です:
カスタムSSL CA認証局を使用する
ADDITIONAL_CA_CERT_BUNDLE CI/CD変数を使用して、カスタムSSL認証局を設定できます。これは、glabコマンドラインインターフェースがカスタム証明書を使用してHTTPS経由でAPI経由でリリースを作成する際に、ピアを検証するために使用されます。ADDITIONAL_CA_CERT_BUNDLEの値には、X.509 PEM公開キー証明書のテキスト表現、または公開認証局(CA)を含むpath/to/fileが含まれている必要があります。.gitlab-ci.ymlファイルでこの値を設定する例は、以下のとおりです:
release:
variables:
ADDITIONAL_CA_CERT_BUNDLE: |
-----BEGIN CERTIFICATE-----
MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
...
jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
-----END CERTIFICATE-----
script:
- echo "Create release"
release:
name: 'My awesome release'
tag_name: '$CI_COMMIT_TAG'ADDITIONAL_CA_CERT_BUNDLE値は、UIのカスタム変数として設定することもできます。fileとして設定する場合は、証明書のパスが必要です。変数として設定する場合は、証明書のテキスト表現が必要です。
単一のパイプラインで複数のリリースを作成する
パイプラインには、複数のreleaseジョブを含めることができます。例は以下のとおりです:
ios-release:
script:
- echo "iOS release job"
release:
tag_name: v1.0.0-ios
description: 'iOS release v1.0.0'
android-release:
script:
- echo "Android release job"
release:
tag_name: v1.0.0-android
description: 'Android release v1.0.0'汎用パッケージとしてアセットをリリースする
汎用パッケージを使用して、リリースアセットをホスティングできます。
パッケージ化したアセットを使用してリリースを作成するには:
CI/CDパイプラインから、パッケージファイルをビルドします。
glabコマンドラインインターフェースジョブでリリースを作成するには、次の手順に従います:Create Release: stage: release image: registry.gitlab.com/gitlab-org/cli:latest rules: - if: $CI_COMMIT_TAG script: - | glab release create "$CI_COMMIT_TAG" \ --name "Release ${VERSION}" \ --notes "Your release notes here" \ path/to/your/release-asset-file \ --use-package-registry含めるアセットごとに、追加の
--assets-linkリンクを追加します。
将来のリリース
リリースAPIを使用すると、事前にリリースを作成できます。released_atで将来の日付を指定すると、次のリリースバッジがリリースタグの横に表示されます。released_atの日時が経過すると、バッジは自動的に削除されます。
過去のリリース
リリースAPIまたはUIを使用して、過去の日付でリリースを作成できます。released_atで過去の日付を指定すると、過去のリリースバッジがリリースタグの横に表示されます。過去の日付のリリースであるため、リリースエビデンスは利用できません。
リリースを編集する
リリースが作成された後に詳細を編集するには、リリースの更新APIまたはUIを使用できます。
前提要件:
- デベロッパー以上のロールが付与されている必要があります。
UIの場合:
- 左側のサイドバーで、デプロイ > リリースを選択します。
- 変更するEdit this releaseの右上隅のこのリリースを編集(鉛筆アイコン)をクリックします。
- リリースを編集を編集ページで、リリースの詳細を変更します。
- 変更を保存を選択します。
リリースを削除する
リリースを削除すると、リリースのアセットも削除されますが、関連付けられているGitタグは削除されません。リリースに関連付けられたGitタグを削除すると、リリースも削除されます。
前提要件:
- デベロッパー以上のロールが付与されている必要があります。詳細については、リリースの権限を参照してください。
リリースを削除するには、リリースの削除APIか、UIを使用します。
UIの場合:
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- デプロイ > リリースを選択します。
- 削除するEdit this releaseの右上隅のこのリリースを編集( )をクリックします。
- リリースを編集を編集ページで、削除を選択します。
- リリースを削除を選択します。
マイルストーンをリリースに関連付ける
リリースは、単一または複数のプロジェクトマイルストーンに関連付けることができます。
GitLab Premiumのお客様は、リリースに関連付けるグループマイルストーンを指定できます。
これは、UIで実行することも、リリースAPIへのリクエストにmilestones配列を含めることでも実行できます。
UIで、マイルストーンをリリースに関連付けるには:
- 左側のサイドバーで、デプロイ > リリースを選択します。
- 変更するEdit this releaseの右上隅のこのリリースを編集(鉛筆アイコン)をクリックします。
- マイルストーンリストから、関連付ける各マイルストーンを選択します。マイルストーンは複数選択できます。
- 変更を保存を選択します。
デプロイ > リリースページの上部には、マイルストーンと、そのマイルストーンに関連するイシューの統計が表示されます。
リリースは、Plan > マイルストーンページ、およびこのページでマイルストーンを選択した場合にも表示されます。
リリースがないマイルストーン、1つのリリースがあるマイルストーン、2つのリリースがあるマイルストーンの例は以下のとおりです。
サブグループのプロジェクトリリースを親グループのマイルストーンに関連付けることはできません。詳細については、イシュー#328054リリースをスーパーグループマイルストーンに関連付けることができないを参照してください。
リリース作成時に通知を受け取る
プロジェクトの新しいリリースが作成される際に、メールで通知を受け取ることができます。
リリースの通知にサブスクライブするには:
- 左側のサイドバーでProject overview(プロジェクトの概要)を選択します。
- Notification setting(ベルのアイコン)をクリックします。
- リストで、カスタムを選択します。
- 新しいリリースチェックボックスをオンにします。
- ダイアログボックスを閉じて保存します。
デプロイフリーズを設定して意図しないリリースを回避する
デプロイフリーズ期間を設定して、指定した期間中の意図しない本番環境リリースを防ぐことができます。デプロイフリーズを使用すると、デプロイを自動化する際の不確実性とリスクの軽減につながります。
メンテナーは、UIでデプロイフリーズウィンドウを設定するか、フリーズ期間APIを使用して、crontabエントリとして定義されているfreeze_startとfreeze_endを設定できます。
実行中のジョブがフリーズ期間内となる場合、GitLab CI/CDは$CI_DEPLOY_FREEZEという名前の環境変数を作成します。
グループ内の複数のプロジェクトでデプロイジョブの実行を防ぐには、グループ全体で共有されるファイルで.freezedeploymentジョブを定義します。includesキーワードを使用して、プロジェクトの.gitlab-ci.ymlファイルにテンプレートを組み込みます。以下に例を示します:
.freezedeployment:
stage: deploy
before_script:
- '[[ ! -z "$CI_DEPLOY_FREEZE" ]] && echo "INFRASTRUCTURE OUTAGE WINDOW" && exit 1; '
rules:
- if: '$CI_DEPLOY_FREEZE'
when: manual
allow_failure: true
- when: on_successデプロイジョブが実行されないようにするには、.gitlab-ci.ymlファイルのdeploy_to_productionジョブでextendsキーワードを使用し、.freezedeploymentテンプレートジョブから設定を継承します:
deploy_to_production:
extends: .freezedeployment
script: deploy_to_prod.sh
environment: productionこの設定により、デプロイジョブが条件付きでブロックされ、パイプラインの継続性が維持されます。フリーズ期間が定義されている場合、ジョブは失敗し、パイプラインはデプロイなしで続行できます。フリーズ期間が終了すると、手動でデプロイできます。
このアプローチは、重要なメンテナンス中のデプロイを制御し、CI/CDパイプラインが中断することなく実行されるようにします。
UIでデプロイフリーズ期間を設定するには、次の手順を実行します:
- メンテナーロールを持つユーザーとしてGitLabにサインインします。
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 設定 > CI/CDを選択します。
- デプロイフリーズまでスクロールします。
- 全て展開を選択して、デプロイフリーズテーブルを表示します。
- デプロイフリーズを追加を選択して、デプロイフリーズモーダルを開きます。
- 目的のデプロイフリーズ期間の開始時刻、終了時刻、およびタイムゾーンを入力します。
- モーダルでデプロイフリーズを追加を選択します。
- デプロイフリーズを保存したら、編集ボタン( )を選択して編集し、削除ボタン( )を選択して削除できます。

プロジェクトに複数のフリーズ期間が含まれている場合、すべての期間が適用されます。それらがオーバーラップしている場合、フリーズは完全にオーバーラップしている期間を対象とします。
詳細については、デプロイの安全性を参照してください。
リリースの権限
リリースを表示してアセットをダウンロードする
- レポーター以上のロールを持つユーザーは、プロジェクトのリリースに対する読み取りおよびダウンロード権限を持っています。
- ゲストロールのユーザーは、プロジェクトのリリースへの読み取りおよびダウンロード権限を持っています。これには、関連付けられているGitタグ名、リリースの説明、リリースの作成者情報が含まれます。ただし、ソースコードやリリースエビデンスなどのリポジトリ関連情報は削除済みのです。
ソースコードへのアクセス権を付与せずにリリースを公開する
プロジェクトメンバー以外のメンバーがリリースにアクセスできるようにしながら、ソースコードやリリースエビデンスなどのリポジトリ関連情報はプロジェクトメンバーのみが利用できるようにすることができます。これらの設定は、ソフトウェアの新しいバージョンへのアクセス権限を付与するためにリリースを使用するが、ソースコードを一般公開したくないプロジェクトに最適です。
リリースを公開するには、次のプロジェクトの表示レベルを設定します:
- プロジェクトの表示レベルを公開に設定します。
- リポジトリを有効にし、プロジェクトメンバーのみに設定します。
- リリースを有効にして、アクセスできる人すべてに設定します。
リリースとリリースのアセットを作成、更新、削除する
- デベロッパー以上のロールを持つユーザーは、プロジェクトのリリースとアセットに対する書き込み権限を持っています。
- リリースが保護タグに関連付けられている場合、ユーザーは保護タグの作成が許可されている必要もあります。
リリースのメンテナー制御の例として、作成が許可されています(*)を使用してタグを保護し、作成が許可されていますコラムでメンテナーを設定することで、メンテナー以上のロールを持つユーザーのみにリリースを作成、更新、および削除することを許可できます。
リリースのメトリクス
- プラン: Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
グループレベルのリリースのメトリクスは、グループ > 分析 > CI/CDに移動すると利用できます。これらのメトリクスには以下が含まれます:
- グループ内のリリースの合計数
- 少なくとも1つのリリースがあるグループ内のプロジェクトの割合
実際のプロジェクト例
Guided ExplorationプロジェクトのGitVersionを使用した完全に自動化されたソフトウェアとアーティファクトのバージョニングでは、以下の実例が示されています:
- GitLabリリースの使用。
- GitLab CLIの使用
- 汎用パッケージの作成。
- パッケージをリリースにリンクする。
- GitVersionという名前のツールを使用して、複雑なリポジトリのバージョンを自動的に決定して増分する。
テストの目的で、このプロジェクト例を独自のグループまたはインスタンスにコピーできます。他のGitLab CIパターンのデモについての詳細は、プロジェクトページをご覧ください。
トラブルシューティング
リリースとそのアセットの作成、更新、または削除時のエラー
リリースが保護タグに関連付けられている場合、UI/APIリクエストが原因で、次の認証エラーが発生する可能性があります:
403 ForbiddenSomething went wrong while creating a new release
ユーザーまたはサービス/ボットアカウントに対して保護タグの作成が許可されていることを確認してください。
詳細については、リリースの権限を参照してください。
ストレージに関する注意
この機能はGitタグの上に構築されているため、リリース自体を作成する以外に、追加のデータはほぼ必要ありません。追加のアセットと自動的に生成されるリリースエビデンスはストレージを消費します。
GitLab CLIのバージョン要件
releaseキーワードの使い方は変更される予定です。release-cliツールはGitLab CLIツールに置き換えられます。
GitLab CLIツールv1.58.0以上を使用する必要があります。それ以外のバージョンの場合、以下のいずれかのエラーメッセージまたは警告が表示される可能性があります:
Error: glab command not found. Please install glab v1.58.0 or higher.Error: Please use glab v1.58.0 or higher.Warning: release-cli will not be supported after 19.0. Please use glab version >= 1.58.0.
GitLab CLIツールを入手する2つの方法:
registry.gitlab.com/gitlab-org/release-cli:<version>コンテナイメージを使用する場合、glabv1.58.0を含むregistry.gitlab.com/gitlab-org/cli:v1.58.0またはregistry.gitlab.com/gitlab-org/release-cli:v0.24.0のどちらかの使用を開始できます。- release-cliまたはGitLab CLIツールを手動でRunnerにインストールした場合は、GitLab CLIバージョンが
v1.58.0以上であることを確認してください。




