0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@GL_TsukasainGitLab合同会社

リリース機能

Posted at

リリース機能

(トップページはこちら) - (アプリケーションのデプロイとリリースを始める)

GitLabのリリース機能は、プロジェクトの重要なマイルストーンにおいて、コード、バイナリ、ドキュメント、リリースノートを統合した完全なスナップショットを作成します。リリースを作成すると、GitLabは自動的にコードにタグを付け、スナップショットをアーカイブし、監査対応可能なエビデンスを生成します。これにより、コンプライアンス要件に対応した永続的な記録が作成され、開発プロセスに対するユーザーの信頼性を高めることができます。

対応エディション: Free、Premium、Ultimate（GitLab.com、GitLab Self-Managed、GitLab Dedicated）

ユーザーは以下のメリットを享受できます。

  • 最新の安定版とインストールパッケージへの簡単なアクセス
  • 新機能と修正に関する明確なドキュメント
  • 対応するアセットを含む特定バージョンのダウンロード機能
  • プロジェクトの進化を時系列で追跡できるシンプルな方法

重要な注意事項: リリースに関連付けられたGitタグを削除すると、リリースも削除されます。

1. リリース機能の概要

1.1 リリースで実現できること

リリースを作成する際、または作成後に以下を追加できます。

  • リリースノート
  • リリースに関連付けられたGitタグのメッセージ
  • マイルストーンとの関連付け
  • ランブックやパッケージなどのリリースアセット

1.2 リリース作成方法の選択ガイド

プロジェクトの状況に応じて、最適な作成方法を選択してください。

状況 推奨方法 理由
定期的なリリースを自動化したい CI/CDパイプライン 人的ミスを削減し、一貫性を確保
手動で細かく制御したい リリースページ UIで直感的に操作可能
外部ツールと連携したい Releases API プログラマティックな制御が可能
複数プラットフォーム向けリリース CI/CDパイプライン（複数ジョブ） iOS、Androidなどを同時リリース

1.3 リリース作成の全体フロー

2. リリースの表示と管理

2.1 リリース一覧の確認

リリース一覧を表示するには、以下の方法があります。

  • 左サイドバーから Deploy > Releases を選択
  • プロジェクトの概要ページで、リリース数を選択

表示権限:

  • パブリックプロジェクト: すべてのユーザーに表示
  • プライベートプロジェクト: 少なくともReporterロールを持つユーザーに表示

2.2 リリースのソート

リリースは Released date（リリース日）または Created date（作成日）でソートできます。昇順・降順の切り替えも可能です。

デフォルトでは、GitLabはreleased_at時刻を使用してリリースを取得します。クエリパラメータ?order_by=released_atの使用はオプションです。

2.3 最新リリースへの永続的リンク

GitLabは最新リリースページへの永続的なリンクを提供します。このURLは常に最新リリースページにリダイレクトされます。

URLの形式:

https://gitlab.example.com/namespace/project/-/releases/permalink/latest

サフィックス付きの例:

gitlab-orgネームスペースのgitlab-runnerプロジェクトで最新リリースがv17.7.0#releaseの場合:

https://gitlab.com/gitlab-org/gitlab-runner/-/releases/permalink/latest#release

この機能により、ドキュメントやスクリプトに固定URLを記載でき、常に最新バージョンを参照できます。

2.4 RSSフィードでリリースを追跡

GitLabはプロジェクトのリリースをAtom形式のRSSフィードで提供します。

フィードの表示手順:

  1. メンバーになっているプロジェクトの場合:
    1. 左サイドバーから Search or go to を選択してプロジェクトを検索
    2. Deploy > Releases を選択
  2. すべてのプロジェクトの場合:
    1. Project overview ページに移動
    2. 右サイドバーで Releases を選択
  3. 右上隅のフィードシンボルを選択

RSSリーダーに登録することで、新しいリリースの通知を自動的に受け取れます。

3. リリースの作成

3.1 リリースページでの作成（UI）

前提条件: プロジェクトに対して少なくともDeveloperロールが必要です。

作成手順:

  1. 左サイドバーから Search or go to を選択してプロジェクトを検索
  2. Deploy > Releases を選択し、New release をクリック
  3. Tag name ドロップダウンリストから既存のGitタグを選択するか、新しいタグ名を入力
    • 既存のタグを選択する場合: すでにリリースに関連付けられているタグを選択すると検証エラーが発生します
    • 新しいタグを作成する場合:
      1. Create tag ポップオーバーから、新しいタグを作成する際に使用するブランチまたはコミットSHAを選択
      2. オプションで、Set tag message テキストボックスにメッセージを入力してアノテーテッドタグを作成
      3. Save を選択
  4. オプションで、追加情報を入力:
    • タイトル
    • マイルストーン
    • リリースノート
    • タグメッセージを含めるかどうか
    • アセットリンク
  5. Create release を選択

3.2 CI/CDジョブによる作成（自動化）

CI/CDパイプラインの一部として、ジョブ定義でreleaseキーワードを使用してリリースを直接作成できます。リリースはパイプラインの最終段階で作成することが推奨されます。

リリースは、ジョブがエラーなく処理された場合にのみ作成されます。リリース作成中にAPIがエラーを返した場合、リリースジョブは失敗します。

パターン1: Gitタグが作成されたときにリリースを作成

stages:
  - build
  - test
  - release

build_job:
  stage: build
  script:
    - echo "アプリケーションをビルド"
    - make build

test_job:
  stage: test
  script:
    - echo "テストを実行"
    - make test

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/cli:latest
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - echo "リリースを作成"
  release:
    tag_name: '$CI_COMMIT_TAG'
    name: 'リリース $CI_COMMIT_TAG'
    description: './CHANGELOG.md'

パターン2: デフォルトブランチへのマージ時にリリースを作成

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/cli:latest
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script:
    - echo "バージョン番号を生成"
  release:
    tag_name: 'v1.0.$CI_PIPELINE_IID'
    name: 'リリース v1.0.$CI_PIPELINE_IID'
    description: '自動生成されたリリース'

パターン3: カスタムスクリプトでリリースメタデータを作成

prepare_release:
  stage: release
  image: registry.gitlab.com/gitlab-org/cli:latest
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - echo "リリースノートを生成"
    - ./scripts/generate_release_notes.sh > release_notes.md
    - |
      glab release create "$CI_COMMIT_TAG" \
        --name "リリース $CI_COMMIT_TAG" \
        --notes-file release_notes.md

3.3 カスタムSSL CA証明書の使用

ADDITIONAL_CA_CERT_BUNDLE CI/CD変数を使用して、カスタムSSL CA証明書を設定できます。この変数は、glab CLIがカスタム証明書を使用してHTTPS経由でAPIを通じてリリースを作成する際に、ピアを検証するために使用されます。

.gitlab-ci.ymlでの設定例:

release:
  variables:
    ADDITIONAL_CA_CERT_BUNDLE: |
        -----BEGIN CERTIFICATE-----
        MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
        ...
        jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
        -----END CERTIFICATE-----
  script:
    - echo "リリースを作成"
  release:
    name: '素晴らしいリリース'
    tag_name: '$CI_COMMIT_TAG'

ADDITIONAL_CA_CERT_BUNDLE値は、UIでカスタム変数として設定することもできます。証明書へのパスが必要なfileとして、または証明書のテキスト表現が必要な変数として設定できます。

3.4 単一パイプラインでの複数リリース作成

1つのパイプラインで複数のreleaseジョブを実行できます。これは、複数プラットフォーム向けのリリースを同時に作成する場合に便利です。

ios-release:
  stage: release
  image: registry.gitlab.com/gitlab-org/cli:latest
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - echo "iOSリリースジョブ"
  release:
    tag_name: v1.0.0-ios
    description: 'iOSリリース v1.0.0'

android-release:
  stage: release
  image: registry.gitlab.com/gitlab-org/cli:latest
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - echo "Androidリリースジョブ"
  release:
    tag_name: v1.0.0-android
    description: 'Androidリリース v1.0.0'

3.5 Generic Packagesとしてのリリースアセット

Generic Packagesを使用してリリースアセットをホストできます。これにより、バイナリファイルやその他のアセットをGitLabのパッケージレジストリに保存し、リリースに関連付けることができます。

完全な設定例:

stages:
  - build
  - upload
  - release

build_package:
  stage: build
  script:
    - echo "パッケージをビルド"
    - make build
    - tar -czf myapp-${CI_COMMIT_TAG}.tar.gz dist/
  artifacts:
    paths:
      - myapp-${CI_COMMIT_TAG}.tar.gz

upload_package:
  stage: upload
  image: curlimages/curl:latest
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - |
      curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" \
           --upload-file myapp-${CI_COMMIT_TAG}.tar.gz \
           "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/myapp/${CI_COMMIT_TAG}/myapp-${CI_COMMIT_TAG}.tar.gz"

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 "リリース ${CI_COMMIT_TAG}" \
        --notes "リリースノートをここに記載" \
        myapp-${CI_COMMIT_TAG}.tar.gz \
        --use-package-registry

含めたいアセットごとに、追加の--assets-linkリンクを追加します。

4. 特殊なリリースタイプ

4.1 予定リリース（Upcoming Releases）

Releases APIを使用して、事前にリリースを作成できます。将来のreleased_at日付を設定すると、リリースタグの横に Upcoming Release バッジが表示されます。released_at日時が過ぎると、バッジは自動的に削除されます。

使用例:

  • 事前にリリース情報を公開し、ユーザーに予告する
  • マーケティングキャンペーンと連動したリリーススケジュールを管理
  • 複数チーム間でリリース日程を共有

4.2 過去リリース（Historical Releases）

導入バージョン: GitLab 15.2

Releases APIまたはUIを使用して、過去のリリースを作成できます。過去のreleased_at日付を設定すると、リリースタグの横に Historical release バッジが表示されます。

重要な制限: 過去にリリースされたため、リリースエビデンスは利用できません。

使用例:

  • 既存プロジェクトをGitLabに移行する際、過去のリリース履歴を再現
  • 以前のリリースを遡って文書化
  • レガシーシステムからのマイグレーション

4.3 予定リリースと過去リリースの比較

項目 予定リリース 過去リリース
released_atの設定 未来の日時 過去の日時
バッジ表示 Upcoming Release Historical release
リリースエビデンス 利用可能 利用不可
主な用途 リリース予告 履歴の再現

5. リリースの編集と削除

5.1 リリースの編集

リリース作成後に詳細を編集できます。Update a release APIまたはUIを使用します。

前提条件: 少なくともDeveloperロールが必要です。

UIでの編集手順:

  1. 左サイドバーから Deploy > Releases を選択
  2. 変更したいリリースの右上隅にある Edit this release（鉛筆アイコン）を選択
  3. Edit Release ページでリリースの詳細を変更
  4. Save changes を選択

編集可能な項目:

  • タイトル
  • リリースノート
  • マイルストーンの関連付け
  • アセットリンク

5.2 リリースの削除

導入バージョン: GitLab 15.2

前提条件: 少なくともDeveloperロールが必要です。

重要な動作:

  • リリースを削除すると、そのアセットも削除されます
  • ただし、関連するGitタグは削除されません
  • 逆に、Gitタグを削除すると、関連するリリースも削除されます

UIでの削除手順:

  1. 左サイドバーから Search or go to を選択してプロジェクトを検索
  2. Deploy > Releases を選択
  3. 削除したいリリースの右上隅にある Edit this release を選択
  4. Edit Release ページで Delete を選択
  5. Delete release を選択

削除時の注意事項:

6. マイルストーンとの関連付け

6.1 マイルストーンの関連付け方法

リリースを1つ以上のプロジェクトマイルストーンに関連付けることができます。GitLab Premiumでは、グループマイルストーンも指定できます。

ユーザーインターフェースまたはReleases APIへのリクエストにmilestones配列を含めることで、この操作を実行できます。

UIでの関連付け手順:

  1. 左サイドバーから Deploy > Releases を選択
  2. 変更したいリリースの右上隅にある Edit this release（鉛筆アイコン）を選択
  3. Milestones リストから関連付けたいマイルストーンを選択（複数選択可能）
  4. Save changes を選択

6.2 マイルストーンとリリースの関係

Deploy > Releases ページでは、Milestone がトップセクションに表示され、マイルストーン内のイシューに関する統計情報も確認できます。

リリースは Plan > Milestones ページでも表示され、このページでマイルストーンを選択したときにも確認できます。

マイルストーンとリリースの統合例:

  • マイルストーン「バージョン 1.0」に10個のイシューが含まれる
  • そのうち8個が完了し、2個が未完了
  • リリース「v1.0.0」をこのマイルストーンに関連付け
  • リリースページで、マイルストーンの進捗状況（80%完了）が表示される

制限事項: サブグループのプロジェクトリリースは、親グループのマイルストーンに関連付けることができません。

6.3 マイルストーンを活用したリリース管理

7. リリース作成時の通知

7.1 通知の設定

新しいリリースが作成されたときにメール通知を受け取ることができます。

通知購読の手順:

  1. 左サイドバーから Project overview を選択
  2. Notification setting（ベルアイコン）を選択
  3. リストから Custom を選択
  4. New release チェックボックスを選択
  5. ダイアログボックスを閉じて保存

通知のタイミング:

  • リリースがUIで作成されたとき
  • CI/CDパイプラインでリリースが作成されたとき
  • APIでリリースが作成されたとき

通知内容:

  • リリース名
  • タグ名
  • リリースノートの概要
  • リリースへのリンク

8. デプロイフリーズによる意図しないリリースの防止

8.1 デプロイフリーズの概要

デプロイフリーズ期間を設定することで、指定した期間中の意図しない本番リリースを防止できます。デプロイフリーズは、デプロイの自動化における不確実性とリスクを軽減します。

使用例:

  • 年末年始やゴールデンウィークなどの長期休暇期間
  • 重要なイベントやキャンペーン期間中
  • システムメンテナンス期間
  • 監査期間中

8.2 デプロイフリーズの仕組み

メンテナーは、UIまたはFreeze Periods APIを使用して、freeze_startとfreeze_endをcrontabエントリとして定義できます。

フリーズ期間中にジョブが実行される場合、GitLab CI/CDは$CI_DEPLOY_FREEZEという環境変数を作成します。

8.3 デプロイフリーズの設定

グループ全体での設定:

グループ内の複数プロジェクトでデプロイジョブの実行を防ぐには、グループ全体で共有されるファイルに.freezedeploymentジョブを定義します。

# グループ共有ファイル: .gitlab-ci-templates/freeze-deployment.yml
.freezedeployment:
  stage: deploy
  before_script:
    - '[[ ! -z "$CI_DEPLOY_FREEZE" ]] && echo "インフラストラクチャメンテナンス期間" && exit 1; '
  rules:
    - if: '$CI_DEPLOY_FREEZE'
      when: manual
      allow_failure: true
    - when: on_success

プロジェクトでの使用:

プロジェクトの.gitlab-ci.ymlファイルでextendsキーワードを使用して、.freezedeploymentテンプレートジョブから設定を継承します。

include:
  - project: 'group/ci-templates'
    file: '.gitlab-ci-templates/freeze-deployment.yml'

deploy_to_production:
  extends: .freezedeployment
  script: deploy_to_prod.sh
  environment: production

この設定は、デプロイジョブを条件付きでブロックし、パイプラインの継続性を維持します。フリーズ期間が定義されている場合、ジョブは失敗し、パイプラインはデプロイなしで続行できます。フリーズ期間後に手動デプロイが可能です。

8.4 UIでのデプロイフリーズ設定

設定手順:

  1. Maintainerロールでサインイン
  2. 左サイドバーから Search or go to を選択してプロジェクトを検索
  3. Settings > CI/CD を選択
  4. Deploy freezes までスクロール
  5. Expand を選択してデプロイフリーズテーブルを表示
  6. Add deploy freeze を選択してモーダルを開く
  7. 開始時刻、終了時刻、タイムゾーンを入力
  8. モーダルで Add deploy freeze を選択
  9. デプロイフリーズが保存された後、編集ボタンを選択して編集、削除ボタンを選択して削除できます

複数フリーズ期間の動作:

プロジェクトに複数のフリーズ期間が含まれる場合、すべての期間が適用されます。重複する場合は、完全な重複期間がフリーズ対象となります。

8.5 デプロイフリーズの動作フロー

9. リリース権限

9.1 権限の概要

GitLabのリリース機能には、きめ細かい権限設定があります。プロジェクトの可視性とユーザーロールに応じて、アクセス権が異なります。

9.2 権限マトリクス

操作 Guest Reporter Developer Maintainer 備考
リリース一覧の表示 ○ ○ ○ ○ プライベートプロジェクトの場合
リリースのダウンロード ○ ○ ○ ○ -
ソースコードの表示 × ○ ○ ○ Guestは編集される
リリースエビデンスの表示 × ○ ○ ○ Guestは編集される
リリースの作成 × × ○ ○ -
リリースの編集 × × ○ ○ -
リリースの削除 × × ○ ○ -
保護されたタグのリリース作成 × × △ ○ 保護されたタグの作成権限が必要

9.3 リリースの表示とアセットのダウンロード

Reporterロール以上:

  • プロジェクトリリースへの完全な読み取りおよびダウンロードアクセス権を持ちます
  • すべてのリリース情報、ソースコード、リリースエビデンスにアクセス可能

Guestロール:

  • プロジェクトリリースへの読み取りおよびダウンロードアクセス権を持ちます
  • 関連するGitタグ名、リリース説明、リリースの作成者情報にアクセス可能
  • ただし、ソースコードやリリースエビデンスなど、他のリポジトリ関連情報は編集されます

9.4 ソースコードへのアクセスを与えずにリリースを公開

導入バージョン: GitLab 15.6

リリースを非プロジェクトメンバーがアクセス可能にしながら、ソースコードやリリースエビデンスなどのリポジトリ関連情報をプロジェクトメンバーのみが利用できるようにすることができます。

使用例:

  • オープンソースプロジェクトでバイナリのみを公開
  • 商用ソフトウェアのリリース版を配布
  • プロプライエタリなコードを保護しながらリリースを提供

設定方法:

以下のプロジェクト設定を行います。

  1. Project visibility を Public に設定
  2. Repository を有効にし、Only Project Members に設定
  3. Releases を有効にし、Everyone With Access に設定

この設定の効果:

項目 プロジェクトメンバー 非メンバー
リリース一覧 表示可能 表示可能
リリースノート 表示可能 表示可能
アセットのダウンロード 可能 可能
ソースコード 表示可能 表示不可
リリースエビデンス 表示可能 表示不可
リポジトリのクローン 可能 不可

9.5 リリースとアセットの作成、更新、削除

Developerロール以上:

  • プロジェクトリリースとアセットへの書き込みアクセス権を持ちます
  • リリースの作成、編集、削除が可能

保護されたタグの場合:

  • リリースが保護されたタグに関連付けられている場合、ユーザーは保護されたタグの作成も許可されている必要があります

権限制御の例:

ワイルドカード（*）でタグを保護し、Allowed to create 列で Maintainer を設定することで、少なくともMaintainerロールを持つユーザーのみがリリースを作成、更新、削除できるようにすることができます。

設定手順:

  1. Settings > Repository を選択
  2. Protected tags セクションを展開
  3. Tag フィールドに * を入力
  4. Allowed to create で Maintainers を選択
  5. Protect を選択

これにより、すべてのタグが保護され、Maintainer以上のロールを持つユーザーのみがリリースを作成できるようになります。

10. リリースメトリクス（Ultimate版）

対象エディション: Ultimate版（GitLab.com、GitLab Self-Managed、GitLab Dedicated）

導入バージョン: GitLab Premium 13.9

10.1 利用可能なメトリクス

グループレベルのリリースメトリクスは、Group > Analytics > CI/CD から利用できます。

メトリクスの内容:

  1. グループ内のリリースの総数

    • グループ内のすべてのプロジェクトで作成されたリリースの合計数
    • 時系列での推移を確認可能

  2. 少なくとも1つのリリースを持つプロジェクトの割合

    • リリース機能を活用しているプロジェクトの比率
    • リリース文化の浸透度を測定

10.2 メトリクスの活用方法

組織全体のリリース状況を把握:

  • どのプロジェクトがリリースを作成しているか
  • リリース頻度の傾向
  • リリース文化の浸透度

改善活動への活用:

  • リリースを作成していないプロジェクトへの支援
  • リリースプロセスの標準化
  • ベストプラクティスの共有

11. 実践例プロジェクト

11.1 GitVersionを使用した自動バージョニング

Guided Explorationプロジェクト「Utterly Automated Software and Artifact Versioning with GitVersion」では、以下を実演しています。

実演内容:

  1. GitLabリリースの使用

    • CI/CDパイプラインでの自動リリース作成
    • リリースノートの自動生成

  2. GitLab CLIの使用

    • glabコマンドを使用したリリース操作
    • スクリプトからのリリース作成

  3. Generic Packageの作成

    • ビルド成果物のパッケージ化
    • パッケージレジストリへのアップロード

  4. パッケージとリリースのリンク

    • リリースへのアセット添付
    • ダウンロードリンクの自動生成

  5. GitVersionツールの使用

    • 複雑なリポジトリのバージョン自動決定
    • セマンティックバージョニングの自動インクリメント
    • ブランチ戦略に基づくバージョン管理

11.2 プロジェクトの活用方法

このプロジェクトを自分のグループまたはインスタンスにコピーしてテストできます。プロジェクトページには、他のGitLab CIパターンの詳細が記載されています。

学習のポイント:

  • 実際に動作する完全な設定例
  • ベストプラクティスの実装
  • 複雑なシナリオへの対応方法

12. トラブルシューティング

12.1 リリースとアセットの作成、更新、削除時のエラー

症状:

リリースが保護されたタグに関連付けられている場合、UI/APIリクエストが認証失敗になることがあります。

エラーメッセージ:

  • 403 Forbidden
  • Something went wrong while creating a new release

原因:

ユーザーまたはサービス/ボットアカウントが保護されたタグの作成権限を持っていない。

解決方法:

  1. Settings > Repository > Protected tags を確認
  2. ユーザーまたはサービスアカウントが Allowed to create に含まれているか確認
  3. 含まれていない場合は、権限を追加

CI/CDでの対処:

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/cli:latest
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - echo "リリースを作成"
  release:
    tag_name: '$CI_COMMIT_TAG'
    name: 'リリース $CI_COMMIT_TAG'
    description: 'リリースノート'
  # CI/CDジョブトークンに保護されたタグの作成権限が必要

12.2 ストレージに関する注意

ストレージ消費の内訳:

この機能はGitタグの上に構築されているため、リリース自体を作成する以外に追加データはほとんど必要ありません。

ストレージを消費する要素:

  • 追加のアセット（バイナリファイル、ドキュメントなど）
  • 自動生成されるリリースエビデンス

ストレージ最適化のヒント:

  • 大きなバイナリファイルはGeneric Packagesを使用
  • 不要な古いリリースは削除を検討
  • リリースエビデンスのサイズを考慮

12.3 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 20.0. Please use glab version >= 1.58.0.

対処方法:

方法1: コンテナイメージの更新

registry.gitlab.com/gitlab-org/release-cli:<version>コンテナイメージを使用している場合:

# 古い設定
release_job:
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  # ...

# 新しい設定（推奨）
release_job:
  image: registry.gitlab.com/gitlab-org/cli:v1.58.0
  # または
  # image: registry.gitlab.com/gitlab-org/release-cli:v0.24.0
  # ...

方法2: 手動インストールの更新

ランナーにrelease-cliまたはGitLab CLIツールを手動でインストールした場合:

# バージョン確認
glab version

# v1.58.0未満の場合は更新
# インストール方法はGitLab CLIドキュメントを参照

移行のタイムライン:

  • GitLab 20.0以降、release-cliはサポートされなくなります
  • 早めにglab v1.58.0以上への移行を推奨

GitLabのリリース機能は、ソフトウェアデリバリープロセスを体系化し、コンプライアンス要件に対応しながら、ユーザーに信頼性の高いリリースを提供するための強力なツールです。CI/CDパイプラインとの統合により、リリースプロセスを完全に自動化し、開発チームの生産性を向上させることができます。

適切な権限設定とデプロイフリーズの活用により、安全で制御されたリリースプロセスを実現できます。マイルストーンとの連携により、プロジェクト管理とリリース管理を統合し、チーム全体の可視性を高めることができます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?