- リリースの表示
- リリースの作成
- リリース予定
- 過去のリリース
- リリースの編集
- リリースの削除
- マイルストーンとリリースの関連付け
- リリースが作成されたときに通知を受け取るには
- デプロイフリーズを設定して意図しないリリースを防止します。
- リリース権限
- リリースのメトリクス
- 実用例プロジェクト
- トラブルシューティング
リリース
GitLabでは、リリースはインストールパッケージやリリースノートを含む、ユーザー向けのプロジェクトのスナップショットを作成することができます。GitLabリリースはどのブランチでも作成できます。リリースを作成すると、ソースコードのリリースポイントを示すGitタグも作成されます。
リリースには次のようなものがあります：
- リポジトリのソースコードのスナップショット。
- ジョブのアーティファクトから作成された汎用パッケージ。
- コードのリリースバージョンに関連するその他のメタデータ。
- リリースノート
リリースを作成するとき：
- GitLab は自動的にソースコードをアーカイブし、リリースと関連付けます。
- GitLabはリリースの全てをリストしたJSONファイルを自動的に作成するので、リリースの比較や監査ができます。このファイルはリリースエビデンスと呼ばれます。
リリースの作成時や作成後に、以下のことができます：
- リリースノートを追加します。
- リリースに関連する Git タグにメッセージを追加します。
- マイルストーンを関連付けます。
- ランブックやパッケージなどのリリースアセットを添付します。
リリースの表示
リリースの一覧を表示します：
-
左サイドバーで、[デプロイ] > [リリース]を選択するか、または
-
プロジェクトの概要ページで、少なくとも1つのリリースが存在する場合は、リリース数を選択します。
- 公開プロジェクトでは、この数字はすべてのユーザーに公開されます。
- 非公開プロジェクトでは、この番号は少なくともレポーターロールを持つユーザーに表示されます。
リリースの並べ替え
リリースをリリース日順または作成日順に並べ替えるには、並べ替えドロップダウンリストから選択します。昇順と降順を切り替えるには、ソート順を選択してください。
リリースの作成
リリースを作成することができます：
- CI/CDパイプラインでジョブを使用します。
- リリースページで
- リリースAPIを使用します。
CI/CDパイプラインの最後のステップとしてリリースを作成する必要があります。
リリースページでリリースを作成します。
前提条件：
- 少なくともプロジェクトの開発者ロールを持っている必要があります。詳細については、リリース権限をお読みください。
リリースページでリリースを作成するには：
- 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
- 左側のサイドバーで、[デプロイ] > [リリース] を選択し、[新規リリース] を選択します。
- を選択します。 タグ名ドロップダウン・リストから
- 既存の Git タグを選択します。すでにリリースに関連付けられている既存のタグを選択すると、検証エラーが発生します。
- 新しい Git タグ名を入力してください。
- タグの作成ポップオーバーから、新しいタグを作成する際に使用するブランチまたはコミット SHA を選択します。
- オプションです。タグメッセージの設定］テキストボックスに、注釈付きタグを作成するメッセージを入力します。
- Save を選択します。
- オプション。リリースに関する以下の追加情報を入力します：
- リリースの作成を選択します。
CI/CDジョブを使ったリリースの作成
ジョブ定義でrelease キーワード を使うことで、GitLab CI/CD パイプラインの一部として直接リリースを作成することができます。
リリースは、ジョブがエラーなく処理された場合にのみ作成されます。リリース作成中に API がエラーを返した場合、リリースジョブは失敗します。
CI/CD ジョブを使用してリリースを作成する方法は次のとおりです：
カスタムSSL CA認証局の使用
ADDITIONAL_CA_CERT_BUNDLE CI/CD変数を使用して、カスタムSSL CA認証局を設定することができます。これは、release-cli 、カスタム証明書を使用してHTTPSを使用してAPI経由でリリースを作成するときに、ピアの検証に使用されます。ADDITIONAL_CA_CERT_BUNDLE の値には、X.509 PEM 公開鍵証明書のテキスト表現か、作成者を含む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 には証明書へのパスが必要で、変数には証明書のテキスト表現が必要です。
1つのパイプラインで複数のリリースを作成します。
パイプラインは、例えば、複数の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'
アセットをジェネリックパッケージとしてリリース
Generic packagesを使ってリリースアセットをホストすることができます。完全な例については、Release assets as Generic packagesプロジェクトを参照してください。
リリース予定
GitLab 12.1 で導入されました。
Releases API を使うことで、前もってリリースを作成することができます。未来の日付を設定すると、released_at リリースタグの横にUpcoming Releaseバッジが表示さ released_atれます。日時がreleased_at 過ぎると released_at、バッジは自動的に削除されます。
過去のリリース
GitLab 15.2 で導入されました。
Releases APIまたは UI を使って過去のリリースを作成することができます。過去のreleased_at 日付を設定すると、リリースタグの横に過去のリリースバッジが表示されます。過去にリリースされたため、リリースのエビデンスは利用できません。
リリースの編集
リリース作成後にリリースの詳細を編集するには、Update a release APIまたは UI を使用します。
前提条件：
- 少なくともDeveloperロールを持っている必要があります。
UI では
- 左側のサイドバーで、[デプロイ] > [リリース] を選択します。
- 修正したいリリースの右上隅で、[Edit this release]（鉛筆アイコン）を選択します。
- リリースの編集ページで、リリースの詳細を変更します。
- 変更を保存を選択します。
リリースの削除
GitLab 15.2 で導入されました。
リリースを削除すると、そのアセットも削除されます。しかし、関連する Git タグは削除されません。
前提条件：
- 少なくとも開発者ロールを持っている必要があります。リリース権限についての詳細はこちらをご覧ください。
リリースを削除するには、Delete a release APIまたは UI を使用してください。
UI では
- 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
- 左側のサイドバーで、[デプロイ] > [リリース] を選択します。
- 削除するリリースの右上で、[このリリースを編集する({pencil})]を選択します。
- リリースの編集ページで、削除を選択します。
- リリースの削除を選択します。
マイルストーンとリリースの関連付け
リリースを1つ以上のプロジェクトのマイルストーンに関連付けることができます。
GitLab Premiumのお客様は、リリースに関連付けるマイルストーンをグループで指定することができます。
これはユーザーインターフェイスで行うか、またはReleases API へのリクエストにmilestones 配列を含めることで行うことができます。
ユーザーインターフェイスでは、マイルストーンをリリースに関連付けます：
- 左側のサイドバーで、[デプロイ] > [リリース] を選択します。
- 修正したいリリースの右上隅で、[Edit this release]（鉛筆アイコン）を選択します。
- マイルストーンリストから、関連付けたい各マイルストーンを選択します。複数のマイルストーンを選択することもできます。
- 変更を保存を選択します。
デプロイ]>[リリース]ページで、マイルストーンとマイルストーン内のイシューに関する統計情報が上部に表示されます。
リリースは、[計画] > [マイルストーン]ページや、このページでマイルストーンを選択したときにも表示されます。
以下は、リリースなし、リリース 1 回、リリース 2 回のマイルストーンの例です。
リリースが作成されたときに通知を受け取るには
GitLab 12.4で導入されました。
プロジェクトに新しいリリースが作成されると、メールで通知されます。
リリースの通知を購読するには：
- 左のサイドバーでProject overviewを選択します。
- 通知設定（ベルのアイコン）を選択します。
- リストで「カスタム」を選択します。
- 新規リリース］チェックボックスを選択します。
- ダイアログボックスを閉じて保存します。
デプロイフリーズを設定して意図しないリリースを防止します。
デプロイフリーズ期間を設定することで、指定した期間に意図しない本番リリースが行われるのを防ぎます。デプロイフリーズは、デプロイを自動化する際の不確実性とリスクを減らすのに役立ちます。
メンテナーは、ユーザーインターフェイスでデプロイフリーズウィンドウを設定するか、Freeze Periods APIを使用してfreeze_start 、freeze_end 、crontabエントリとして定義します。
実行中のジョブがフリーズ期間にある場合、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 にサインインします。
- 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
- 左サイドバーで、Settings > CI/CDを選択します。
- Deploy freezesまでスクロールします。
- 展開]を選択すると、デプロイフリーズの表が表示されます。
- Add deploy freeze（デプロイ フリーズの追加）]を選択し、デプロイ フリーズ モーダルを開きます。
- 希望のデプロイフリーズ期間の開始時刻、終了時刻、およびタイムゾーンを入力します。
- モーダルで［デプロイフリーズを追加］を選択します。
- デプロイフリーズが保存されたら、編集ボタン({pencil}) を選択して編集し、削除ボタン({remove}) を選択して削除できます。
プロジェクトに複数のフリーズ期間がある場合、すべての期間が適用されます。複数の期間が重なっている場合、フリーズは重なっている期間すべてに適用されます。
詳しくは、「展開の安全性」をご覧ください。
リリース権限
GitLab 14.1では、作成、更新、削除アクションの権限モデルの修正が導入されました。
リリースの閲覧とアセットのダウンロード
GitLab14.5でゲストロールの変更が導入されました。
- 少なくともレポーターロールを持つユーザーは、プロジェクトリリースの読み込みとダウンロードにアクセスできます。
- Guest ロールを持つユーザーは、プロジェクトリリースの読み込みとダウンロードにアクセスできます。これには、関連するGitタグ名、リリースの説明、リリースの作成者情報が含まれます。ただし、ソースコードや リリースの証拠など、リポジトリに関連するその他の情報は編集されます。
ソースコードへのアクセスを許可しないリリースの公開
GitLab 15.6で導入されました。
ソースコードや リリースエビデンスなどのリポジトリ関連情報を非公開にしたまま、プロジェクトのメンバー以外がリリースにアクセスできるようにすることができます。新しいバージョンのソフトウェアにアクセスするための手段としてリリースを使うが、ソースコードは公開したくないというプロジェクトに使います。
リリースを公開するには、以下のプロジェクト設定を行います：
- リポジトリが有効で、プロジェクトメンバーだけに設定されています。
- リリースを有効にして、「誰でもアクセス可能」に設定します。
リリースとそのアセットの作成、更新、削除
- 少なくともDeveloperロールを持つユーザーは、プロジェクトリリースとアセットへの書き込み権限があります。
- リリースが保護されたタグに関連付けられている場合、ユーザーは保護されたタグの作成も許可されていなければなりません。
リリースの権限制御の例として、ワイルドカード(*)でタグを保護し、作成許可列にメンテナーを設定することで、少なくともメンテナーのロールを持つユーザーのみにリリースの作成、更新、削除を許可することができます。
リリースのメトリクス
GitLab Premium 13.9で導入されました。
グループ> Analytics > CI/CD に移動すると、グループレベルのリリースメトリクスを利用できます。これらのメトリクスには以下が含まれます：
- グループ内の総リリース数
- グループ内で少なくとも1つのリリースがあるプロジェクトの割合
実用例プロジェクト
Guided Exploration プロジェクトでは、GitVersion を使ってソフトウェアとアーティファクトのバージョン管理を完全に自動化する方法を紹介します：
- GitLab リリースを使う
- GitLab
release-cliを使う . - 汎用パッケージの作成
- パッケージをリリースにリンクします。
- GitVersionというツールを使って、複雑なリポジトリのバージョンを自動的に決定し、インクリメントします。
サンプルプロジェクトを自分のグループやインスタンスにコピーしてテストすることができます。他の GitLab CI パターンがどのようなものかについての詳細は、プロジェクトのページでご覧いただけます。
トラブルシューティング
リリースとそのアセットの作成、更新、削除時に403 Forbidden またはSomething went wrong while creating a new release エラーが発生します。
リリースが保護されたタグに関連付けられている場合、UI/APIリクエストは作成者の認証に失敗する可能性があります。ユーザーまたはサービス/ボットのアカウントが、保護されたタグの作成も許可されていることを確認してください。
詳細はリリースの権限を参照してください。
ストレージに関する注意
この機能は Git タグの上に構築されているため、リリースそのものを作成する以外に余分なデータはほとんど必要ありません。追加のアセットと自動的に生成されるリリースのエビデンスは、ストレージを消費します。