リリースを見る
リリースの作成
- 今後のリリース予定
リリースの編集
Git タグにリリースノートを追加
マイルストーンとリリースの関連付け
リリースが作成されたら通知を受け取ります
デプロイフリーズを設定することで、意図しないリリースを防止します。
リリースフィールド
証拠の公開
GitLab Releaser

リリース

GitLab 11.7 で導入されました。

ソースコードの履歴にチェックポイントを導入するには、リリースの時点で Gitタグを割り当てます。しかし、ほとんどの場合、ユーザーが必要とするのは生のソースコードだけではありません。 CI/CD システムによって出力されたコンパイル済みのオブジェクトやその他の資産も必要とします。

GitLabReleaseは、ソース、ビルド出力、アーティファクト、その他コードのリリースバージョンに関連するメタデータのスナップショットです。

GitLabリリースはどのブランチでも作成できます。リリースを作成するとき

GitLabは自動的にソースコードをアーカイブし、リリースと関連付けます。
GitLabはリリースの全てをリストアップしたJSONファイルを自動的に作成するので、リリースの比較や監査ができます。このファイルはリリースエビデンスと呼ばれます。
リリースノートや、リリースに関連するタグのメッセージを追加することができます。

リリースを作成したら、マイルストーンを関連付けたり、ランブックやパッケージなどのリリースアセットを添付することができます。

リリースを見る

GitLab 12.8で導入されました。

リリース一覧を見るには

プロジェクト概要 > リリース、または
プロジェクトの概要ページで、少なくとも1つのリリースが存在する場合は、リリース数をクリックします。
- 公開プロジェクトでは、この番号はすべてのユーザーに公開されます。
- 非公開プロジェクトでは、この数字はレポーター以上の権限を持つユーザーに表示されます。

リリースの作成

GitLab 12.9から導入されたリリースは、GitLab UIで直接作成することができます。

注意:リリースを作成できるのは、開発者権限以上のユーザのみです。リリース権限の詳細については、こちらをご覧ください。

リリースの作成は、ユーザーインターフェイス、またはReleases APIを使用して行うことができます。 CI/CD リリースパイプラインの最後のステップとして、API を使用してリリースノートを追加することをお勧めします。

GitLab UI から新しいリリースを作成するには：

プロジェクト概要 > リリースに移動し、新規リリースボタンをクリックします。
で タグ名ボックスに名前を入力します。
Create fromリストでブランチを選択するか、タグまたはコミット SHA を入力します。
メッセージボックスに、タグに関連するメッセージを入力します。
オプションで リリースノートフィールドにリリースの説明を入力します。このフィールドにはMarkdownを使用し、ファイルをドラッグ・アンド・ドロップすることができます。
- このフィールドを空にすると、タグだけが作成されます。
- これを入力すると、タグとリリースの両方が作成されます。
タグの作成」をクリックします。

リリースを作成した場合は、プロジェクト概要 > リリースで確認できます。タグを作成した場合は、リポジトリ > タグで確認できます。

リリースを編集してマイルストーンやリリースアセットを追加できるようになりました。

今後のリリース予定

GitLab 12.1で導入されました。

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

リリースの編集

GitLab 12.6で導入されました。アセットリンク編集はGitLab 12.10で導入されました。

注意:リリースを編集できるのは、開発者権限以上のユーザのみです。リリース権限の詳細については、こちらをご覧ください。

リリースの詳細を編集するには

プロジェクトの概要 > リリースに移動します。
修正したいリリースの右上で、このリリースの編集（鉛筆アイコン）をクリックします。
リリースの編集ページで、リリースの詳細を変更します。
変更を保存する］をクリックします。

リリースタイトル、ノート、関連マイルストーン、アセットリンクを編集できます。タグやリリース日など、その他のリリース情報を変更するには、Release APIを使用してください。

Git タグにリリースノートを追加

既存のgitタグがあれば、そこにリリースノートを追加することができます。

リリースノートを追加するには、CI/CDリリースパイプラインの最後のステップとしてAPIを使用することをお勧めします。

インターフェイスでは、新しいgitタグにリリースノートを追加します：

プロジェクトのリポジトリ> タグに移動します。
新しいタグをクリックします。
リリースノート]フィールドに、リリースの説明を入力します。 Markdownを使用し、このフィールドにファイルをドラッグ＆ドロップすることができます。
タグの作成」をクリックします。

インターフェイスでは、既存のgitタグにリリースノートを追加します：

プロジェクトのリポジトリ> タグに移動します。
リリースノートの編集（鉛筆のアイコン）をクリックします。
このフィールドではMarkdownを使用し、ファイルをドラッグ＆ドロップすることができます。
変更を保存する］をクリックします。

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

GitLab 12.5で導入されました。
GitLab 13.0のUIでマイルストーンを編集できるように更新しました。

リリースを1つまたは複数のプロジェクトのマイルストーンに関連付けることができます。

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

ユーザーインターフェイスで、マイルストーンをリリースに関連付けることができます：

プロジェクトの概要 > リリースに移動します。
修正したいリリースの右上で、このリリースの編集（鉛筆アイコン）をクリックします。
マイルストーンリストから、関連付けたい各マイルストーンを選択します。複数のマイルストーンを選択することもできます。
変更を保存する］をクリックします。

プロジェクト概要 > リリースのページでは、マイルストーンがマイルストーン内のイシューに関する統計とともに上部に表示されます。

リリースは「イシュー> マイルストーン」ページにも表示され、このページでマイルストーンをクリックすると表示されます。

以下は、それぞれリリースなし、リリース1回、リリース2回のマイルストーンの例です。

リリースが作成されたら通知を受け取ります

GitLab 12.4で導入されました。

あなたのプロジェクトに新しいリリースが作成されると、メールで通知されます。

リリース通知を購読するには

プロジェクトの概要に移動します。
通知設定（ベルのアイコン）をクリックします。
リストで「カスタム」をクリックします。
新規リリースチェックボックスを選択します。
ダイアログボックスを閉じて保存します。

デプロイフリーズを設定することで、意図しないリリースを防止します。

GitLab 13.0から導入されました。

デプロイ凍結期間を設定することで、指定した期間中に意図しない本番リリースが行われることを防ぎます。デプロイ凍結は、デプロイを自動化する際の不確実性とリスクを低減するのに役立ちます。

Freeze Periods APIを使用して、freeze_start とfreeze_endを設定します。これらはcrontabエントリとして定義されます。

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

デプロイジョブが実行されないようにするには、gitlab-ci.yamlにrules エントリを作成します：

deploy_to_production:
  stage: deploy
  script: deploy_to_prod.sh
  rules:
    - if: $CI_DEPLOY_FREEZE == null

プロジェクトに複数の凍結期間が含まれている場合、すべての期間が適用されます。重複している場合、凍結は重複している期間すべてに適用されます。

詳しくは、「展開の安全性」をご覧ください。

リリースフィールド

以下のフィールドは、リリースの作成または編集時に使用できます。

タグ名

リリースタグ名にはリリースのバージョンを含める必要があります。 GitLabではリリースにセマンティック・バージョニングを採用しており、あなたもそうすることをお勧めします。GitLab Policy for Versioningで詳しく説明されているように、(Major).(Minor).(Patch)を使用してください。

例えば、GitLabのバージョン10.5.7：

10 メジャーリリースは10.0.0ですが、しばしば10.0と呼ばれます。
5 マイナーリリースは10.5.0ですが、しばしば10.5と呼ばれます。
7 はパッチ番号です。

例えば、13.10.11のように、バージョン番号のどの部分も複数桁にすることができます。

リリースノート

すべてのリリースには説明があります。好きなテキストを追加することができますが、リリースの内容を説明する変更履歴を含めることをお勧めします。これにより、ユーザはあなたが発行する各リリースの違いを素早く読み取ることができます。

注：gitのタグ付けメッセージとリリースノートの説明は無関係です。説明はMarkdownをサポートしています。

資産の放出

現在、各リリースには以下の種類のアセットを追加できます：

ソースコード
リンク

GitLabは今後、ビルド済みパッケージ、コンプライアンス/セキュリティの証拠、コンテナイメージなどのオブジェクトを含む、より多くのアセットタイプをサポートする予定です。

リリース資産へのパーマネントリンク

GitLab 12.9で導入されました。

リリースに関連付けられたアセットには、永続的なURLでアクセスできます。 GitLabは常にこのURLを実際のアセットロケーションにリダイレクトするので、アセットが別の場所に移動しても、同じURLを使い続けることができます。これはリンクの作成や更新時に定義します。

各アセットには、名前、実際のアセットの場所の URL、そしてオプションでfilepath パラメータがあります。このパラメータを指定すると、リリース用のアセットを指す URL が作成されます。 URL の形式は次のとおりです：

https://host/namespace/project/releases/:release/downloads/:filepath

例えば、gitlab-orgネームスペースにv11.9.0-rc2 リリース用のアセットがあり、gitlab.comにgitlab-runner プロジェクトがある場合：

{
  "name": "linux amd64",
  "filepath": "/binaries/gitlab-runner-linux-amd64",
  "url": "https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64"
}

このアセットには直接リンクがあります：

https://gitlab.com/gitlab-org/gitlab-runner/releases/v11.9.0-rc2/downloads/binaries/gitlab-runner-linux-amd64

資産の物理的な場所はいつでも変更可能ですが、直接リンクは変更されません。

ソースコード

GitLabは自動的に指定されたGitタグからzip、tar.gz、tar.bz2 、tarアーカイブされたソースコードを生成します。これらは読み取り専用のアセットです。

リンク集

リンクとは、ドキュメントやビルドしたバイナリ、その他の関連資料など、好きなものを指すURLのことです。 GitLabインスタンスからの内部リンクでも外部リンクでもかまいません。

リンクの4つのタイプは “Runbook”、”Package”、”Image”、”Other “です。

証拠の公開

GitLab 12.6 で導入されました。

リリースが作成されるたびに、GitLabはそのリリースに関連するデータのスナップショットを取ります。このデータはJSONファイルに保存され、リリースエビデンスと呼ばれます。リンクされたマイルストーンやイシューが含まれ、外部監査のような内部プロセスを促進することができます。

リリースのエビデンスにアクセスするには、「リリース」ページで「エビデンス」コレクションの見出しの下に表示されているJSONファイルへのリンクをクリックします。

APIを使用して既存のリリースのリリース・エビデンスを生成することもできます。このため、各リリースは複数のリリース・エビデンス・スナップショットを持つことができます。リリース・ページでリリース・エビデンスとその詳細を表示できます。

注：イシュー・トラッカーが無効になっている場合、リリースのエビデンスをダウンロードすることはできません。

以下はリリース証拠オブジェクトの例です：

{
  "release": {
    "id": 5,
    "tag_name": "v4.0",
    "name": "New release",
    "project": {
      "id": 20,
      "name": "Project name",
      "created_at": "2019-04-14T11:12:13.940Z",
      "description": "Project description"
    },
    "created_at": "2019-06-28 13:23:40 UTC",
    "description": "Release description",
    "milestones": [
      {
        "id": 11,
        "title": "v4.0-rc1",
        "state": "closed",
        "due_date": "2019-05-12 12:00:00 UTC",
        "created_at": "2019-04-17 15:45:12 UTC",
        "issues": [
          {
            "id": 82,
            "title": "The top-right popup is broken",
            "author_name": "John Doe",
            "author_email": "john@doe.com",
            "state": "closed",
            "due_date": "2019-05-10 12:00:00 UTC"
          },
          {
            "id": 89,
            "title": "The title of this page is misleading",
            "author_name": "Jane Smith",
            "author_email": "jane@smith.com",
            "state": "closed",
            "due_date": "nil"
          }
        ]
      },
      {
        "id": 12,
        "title": "v4.0-rc2",
        "state": "closed",
        "due_date": "2019-05-30 18:30:00 UTC",
        "created_at": "2019-04-17 15:45:12 UTC",
        "issues": []
      }
    ],
    "report_artifacts": [
      {
        "url":"https://gitlab.example.com/root/project-name/-/jobs/111/artifacts/download"
      }
    ]
  }
}

リリース証拠の収集

GitLab Premium12.10 で導入されました。

リリースが作成されると、リリースのエビデンスが自動的に収集されます。それ以外のタイミングでエビデンスの収集を開始するには、APIコールを使用します。 1つのリリースに対して、リリースのエビデンスを複数回収集できます。

証拠収集のスナップショットは、証拠が収集されたタイムスタンプとともに、リリースページに表示されます。

リリースの証拠としてレポートのアーティファクトを添付

GitLab Ultimate13.2で導入されました。

リリースを作成する際、ジョブのアーティファクトが最後に実行されたパイプラインに含まれている場合、それらは自動的にリリースエビデンスとしてリリースに含まれます。

通常、ジョブのアーティファクトには有効期限がありますが、リリース・エビデンスに含まれるアーティファクトには有効期限がありません。

ジョブのアーティファクト収集を有効にするには、両方を指定する必要があります：

ruby:
  script:
    - gem install bundler
    - bundle install
    - bundle exec rspec --format progress --format RspecJunitFormatter --out rspec.xml
  artifacts:
    paths:
      - rspec.xml
    reports:
      junit: rspec.xml

パイプラインが正常に実行されると、リリースの作成時にrspec.xml ファイルがリリースのエビデンスとして保存されます。

注：証拠収集のリリースをスケジュールした場合、証拠収集の時点ですでに有効期限が切れているアーティファクトがある可能性があります。これを回避するには、artifacts:expire_in キーワードを使用することができます。詳しくは](../../../ci/yaml/README.md#artifactsexpire_in)この](../../../ci/yaml/README.md#artifactsexpire_in)イシューをご覧ください。

スケジュールリリース証拠収集

GitLab 12.8で導入されました。

APIで：

将来のreleased_at 日付を指定した場合、リリースは近日リリースとなり、リリース日に証拠が収集されます。それ以前にリリースの証拠を収集することはできません。
過去の日付（released_at ）を使用した場合、証拠は収集されません。
released_at の日付を指定しない場合、リリースの証拠はリリースが作成された日に収集されます。

リリース証拠の表示を無効にします。

:release_evidence_collection 機能フラグは、GitLabセルフマネージドインスタンスではデフォルトで有効になっています。これをオフにするには、RailsコンソールにアクセスできるGitLab管理者に次のコマンドを実行してもらいます：

Feature.disable(:release_evidence_collection)

注：リリース証拠は、この機能フラグに関係なく収集され、リリースページでのデータの表示のみ有効または無効になります。

GitLab Releaser

GitLab 12.10 で導入されました。

GitLab ReleaserはGitLab ReleasesをコマンドラインやGitLabのCI/CD設定ファイル.gitlab-ci.ymlから管理するCLIツールです。

ターミナルからリリースの作成、更新、変更、削除ができます。

詳しくはGitLab Releaserのドキュメントをお読みください。

リリース

リリース

リリースを見る

リリースの作成

今後のリリース予定

リリースの編集

Git タグにリリースノートを追加

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

リリースが作成されたら通知を受け取ります

デプロイフリーズを設定することで、意図しないリリースを防止します。

リリースフィールド

タグ名

リリースノート

資産の放出

リリース資産へのパーマネントリンク

ソースコード

リンク集

証拠の公開

リリース証拠の収集

リリースの証拠としてレポートのアーティファクトを添付

スケジュールリリース証拠収集

リリース証拠の表示を無効にします。

GitLab Releaser

クリエーションラインについて