環境とデプロイメント

GitLab 8.9 で導入されました。

GitLabでは、ソフトウェアの継続的デプロイメントを環境によって制御することができます。

導入

ソフトウェア開発プロセスでは、ソフトウェアが市場に提供されるまでに多くのステップが必要です。

使用例：

開発する
テストする
プロダクトを公開する前に、テスト環境やステージング環境にデプロイしましょう。

これは、ソフトウェアのバグを見つけるのに役立ちます。また、デプロイメントプロセスにおいても同様です。

GitLab CI/CDは、プロジェクトのテストやビルドだけでなく、インフラストラクチャへのデプロイも可能です。これは、デプロイを追跡する方法を提供するという付加的なメリットになります。言い換えれば、現在何がデプロイされているのか、あるいはサーバーにデプロイされているのかを常に知ることができます。

重要なこと:

環境はCIジョブのタグのようなもので、コードがデプロイされる場所を記述します。
ジョブが環境にコードのバージョンをデプロイするときにデプロイメントが作成されるので、すべての環境に1つ以上のデプロイメントを持つことができます。

GitLab:

各環境のデプロイの完全な履歴を提供します。
デプロイメントを追跡することで、現在何がサーバーにデプロイされているかを常に知ることができます。

Kubernetesなどのプロジェクトに関連するデプロイサービスがあれば、それを使ってデプロイを支援したり、GitLab内から自分の環境のWebターミナルにアクセスすることができます。

環境設定

環境の設定には、以下を含みます:

パイプラインの仕組みを理解する
プロジェクトの.gitlab-ci.yml ファイルで環境を定義します。
アプリケーションをデプロイするように設定されたジョブを作成します。たとえば、environment で設定されたデプロイジョブは、アプリケーションを Kubernetesクラスターにデプロイします。

このセクションの残りの部分では、シナリオの例を挙げて環境とデプロイメントを設定する方法を説明します。すでに以下のことを行っていることを想定しています:

GitLabでプロジェクトを作成する
Runnerを設定する

シナリオは次のような内容です:

アプリケーションを開発しています
すべてのブランチでアプリのテスト実行とビルドをしたいと考えています
デフォルトのブランチはmasterです。
master ブランチのパイプラインが実行されたときにのみ、アプリをデプロイします。

環境の定義

次の.gitlab-ci.yml の例を見てみましょう：

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script: echo "Running tests"

build:
  stage: build
  script: echo "Building the app"

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - master

3つのステージを定義しています:

test
build
deploy

これらのステージに割り当てられたジョブは、この順番で実行されます。いずれかのジョブが失敗した場合、パイプラインは失敗し、次のステージに割り当てられたジョブは実行されません。

この場合は:

test のジョブが最初に実行されます。
それからbuild 。
最後にdeploy_staging のジョブ。

この設定では:

テストが通過することを確認します
アプリが正常にビルドできることを確認します
最後に、ステージングサーバーにデプロイします

注:environment キーワードはアプリがデプロイされる場所を定義します。環境name とurl は GitLab 内のさまざまな場所で公開されています。環境が指定されたジョブが成功するたびに、デプロイが Git SHA と環境名とともに記録されます。

注意: 環境名には使用できない文字があります。英字、数字、スペース、および-,_,/,{,},.のみを使用してください。また、/で始まったり、で終わったりしてはいけません。

まとめると、上記.gitlab-ci.yml 、私たちは以下のことを達成しました：

すべてのブランチでtest とbuild のジョブが実行されます。
deploy_staging ジョブはmasterブランチでのみ実行されます。つまり、ブランチから作成されたマージリクエストはすべてステージングサーバーにはデプロイされません。
マージリクエストがマージされると、すべてのジョブが実行され、deploy_stagingジョブはステージングサーバーにコードをデプロイし、デプロイはstagingという名前の環境に記録されます。

環境変数, Runner

GitLab 8.15以降、環境名は2つの方式でRunnerに公開されます:

$CI_ENVIRONMENT_NAME.gitlab-ci.yml で指定された名前（変数があれば展開）。
$CI_ENVIRONMENT_SLUGURLやDNSなどで使用するのに適した、「クリーンアップ」された名前のバージョン。

既存の環境の名前を変更した場合:

$CI_ENVIRONMENT_NAME 変数が新しい環境名で更新されます。
$CI_ENVIRONMENT_SLUG 変数が変更されないのは、意図しない副作用を防ぐためです。

GitLab 9.3から、環境URLは$CI_ENVIRONMENT_URL経由でRunnerに公開されるようになりました。 URLはどちらかから展開されます：

.gitlab-ci.yml.
.gitlab-ci.ymlで定義されていない場合は、環境からの内部 URL。

ジョブ終了後に動的環境の URL を設定する

GitLab 12.9で導入されました。

ジョブスクリプトでは、静的な環境URLを指定することができます。しかし、動的なURLが必要な場合もあります。例えば、デプロイごとにランダムなURLを生成する外部ホスティングサービスにレビューアプリをデプロイする場合、https://94dd65b.amazonaws.com/qa-lambda-1234567、デプロイスクリプトが終了する前にURLを知ることはできません。 GitLabで環境URLを使用する場合は、手動で更新する必要があります。

この問題に対処するために、デプロイジョブを設定して、外部サービスによって動的に生成された URL を含む変数のセットをレポートバックすることができます。 GitLab はdotenv (.env) ファイル形式をサポートしており、environment:url の値を.env ファイルで定義された変数で展開します。

この機能を使用するには、.gitlab-ci.ymlでartifacts:reports:dotenv キーワードを指定します。

概要については、ジョブ終了後に動的URLを設定するを参照してください。

動的環境URLの設定例

次の例では、マージリクエストごとに新しい環境を作成するレビューアプリを示しています。review ジョブはプッシュされるたびにトリガーされ、review/your-branch-nameという名前の環境を作成または更新します。環境の URL は$DYNAMIC_ENVIRONMENT_URLに設定されます：

review:
  script:
    - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                 # In script, get the environment URL.
    - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # Add the value to a dotenv file.
  artifacts:
    reports:
      dotenv: deploy.env                                                       # Report back dotenv file to rails.
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: $DYNAMIC_ENVIRONMENT_URL                                              # and set the variable produced in script to `environment:url`
    on_stop: stop_review

stop_review:
  script:
    - ./teardown-environment
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

review のジョブが終了するとすぐに、GitLab はreview/your-branch-name環境の URL を更新します。deploy.env レポートアーティファクトを解析し、実行時に作成された変数リストを登録し、environment:url: $DYNAMIC_ENVIRONMENT_URL の展開に使用し、環境の URL に設定します。https://$DYNAMIC_ENVIRONMENT_URLのように、environment:url:で URL の静的な部分を指定することもできます。DYNAMIC_ENVIRONMENT_URL の値がexample.comの場合、最終的な結果はhttps://example.comになります。

review/your-branch-name 環境に割り当てられた URL がUI に表示されます。

注:

stop_review はdotenvレポートのアーティファクトを生成しないので、DYNAMIC_ENVIRONMENT_URL 変数を認識しません。したがって、stop_review ジョブでenvironment:url: を設定すべきではありません。
環境URLが有効でない場合(URLが不正な場合など)、システムは環境URLを更新しません。

手動デプロイメント設定

自動実行されるジョブの設定にwhen: manual を追加すると、手動操作が必要なジョブに変換されます。

先ほどの例を発展させるために、production 環境によって追跡される、アプリを本番サーバーにデプロイする別のジョブを以下に示します。

そのための.gitlab-ci.yml ファイルは以下の通りです：

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script: echo "Running tests"

build:
  stage: build
  script: echo "Building the app"

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - master

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
  when: manual
  only:
    - master

when: manual アクション：

GitLab の UI 上に、そのジョブの “play” ボタンが表示されます。
つまり、deploy_prod のジョブは、”play” ボタンがクリックされたときのみ起動されます。

“play” ボタンは、パイプライン、環境、デプロイメント、ジョブの各ビューに存在します。

表示	スクリーンショット
パイプライン
単一パイプライン
環境
デプロイメント
ジョブ

どのビューでも再生ボタンをクリックすると、deploy_prod ジョブがトリガーされ、productionという新しい環境としてデプロイが記録されます。

注：環境名がproduction （すべて小文字）の場合、productionValue Stream Analyticsにproduction記録されます。

動的環境の設定

ステージングや本番環境のような「安定した」環境にデプロイする場合は、通常の環境が良いでしょう。

しかし、master以外のブランチの環境については、動的環境を使うことができます。動的環境では、.gitlab-ci.ymlで動的に名前を宣言することで、その場で環境を作成することができます。

動的環境は Review Apps の基本的な部分です。

使用可能な変数

動的環境用のname とurl パラメーターは、CI/CD で利用可能なほとんどの変数を使用できます：

ただし、定義済み変数は使えません:

アンダーscript.
Runnerで定義されている変数

また、environment:nameのコンテキストではサポートされていない変数もあります。詳しくは、変数が使用できる場所を参照してください。

設定例

GitLab Runner は、ジョブの実行時にさまざまな環境変数を公開します。

以下の例では、ジョブはmasterを除くすべてのブランチにデプロイされます：

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com
  only:
    - branches
  except:
    - master

この例では:

ジョブ名はdeploy_review 、deploy ステージで実行されます。
environment environment:name review/$CI_COMMIT_REF_NAME環境名にはスラッシュ（/）を含めることができるので、このパターンを使って動的環境と通常の環境を区別することができます。
ジョブにブランチでonly 、except master。

このような値の場合:

environment:name最初の部分はreview、続いて/ 、そして$CI_COMMIT_REF_NAME、ブランチ名の値を受け取ります。
environment:url$CI_COMMIT_REF_NAME、ドメイン名やURLでは無効となるやその他の文字が含まれている可能性があるため、、有効なURLの取得を保証します。/ $CI_ENVIRONMENT_SLUG
例えば、100-Do-The-Thingという$CI_COMMIT_REF_NAME を指定すると、URLはhttps://100-do-the-4f99a2.example.comのようになります。繰り返しますが、ウェブサーバーがこれらのリクエストに対応するように設定する方法は、あなたの設定に基づいています。
ここでは$CI_ENVIRONMENT_SLUG を使いましたが、これは一意であることが保証されているからです。GitLab Flow のようなワークフローを使っている場合、衝突する可能性は低く、ブランチ名に近い環境名を好むかもしれません。その場合、$CI_COMMIT_REF_NAME をenvironment:url で使うことができます。上の例ではhttps://$CI_COMMIT_REF_NAME.example.comとなり、URL はhttps://100-do-the-thing.example.comとなります。

注意:動的環境の名前に同じ接頭辞やスラッシュ (/) だけを使う必要はありません。しかし、この形式を使うことで類似環境のグループ化機能が有効になります。

Kubernetesデプロイメントの設定

GitLab 12.6 で導入されました。

プロジェクトに関連付けられたKubernetesクラスターにデプロイする場合は、gitlab-ci.yml ファイルからこれらのデプロイを設定できます。

以下の設定オプションがサポートされています:

namespace

以下の例では、ジョブはアプリケーションをproduction Kubernetes ネームスペースにデプロイします。

deploy:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
    kubernetes:
      namespace: production
  only:
    - master

GitLab の Kubernetes 連携を利用して Kubernetes クラスタにデプロイする場合、クラスタとネームスペースに関する情報がデプロイジョブのページのジョブのトレース情報に表示されます:

注：Kubernetesの設定は、GitLabによって管理されているKubernetesクラスタではサポートされていません。 GitLabによって管理されているクラスタのサポートの進捗状況については、関連するイシューを参照してください。

インクリメンタルロールアウト設定

インクリメンタルロールアウトを使用して、Kubernetesポッドの一部のみに本番の変更をリリースする方法を学びます。

デプロイメントの安全性

デプロイメントのジョブは、パイプラインの中の他のジョブよりも外部の影響を受けやすいので、丁寧なケアが必要になるかもしれません。GitLab には、デプロイメントのセキュリティと安定性を維持するための複数の機能があります。

完成例

このセクションの設定では、アプリが以下のような完全な開発ワークフローを提供します:

テスト
ビルド
Review Appとしてデプロイ
マージリクエストがマージされたら、ステージングサーバーにデプロイ
最後に、本番サーバーに手動でデプロイ

以下は、これまでの設定例を組み合わせたものです:

テスト、ビルド、ステージングへの展開のためのシンプルな環境の定義
本番環境へのデプロイ用に手動アクションを追加
レビュー用のデプロイメントのための動的環境を作成

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script: echo "Running tests"

build:
  stage: build
  script: echo "Building the app"

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com
  only:
    - branches
  except:
    - master

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - master

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
  when: manual
  only:
    - master

より現実的な例としては、ウェブサーバ（例えばNGINX）がアクセスしてサービスを提供できる場所にファイルをコピーすることも含みます。

以下の例では、public ディレクトリを/srv/nginx/$CI_COMMIT_REF_SLUG/publicにコピーします：

review_app:
  stage: deploy
  script:
    - rsync -av --delete public /srv/nginx/$CI_COMMIT_REF_SLUG
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_COMMIT_REF_SLUG.example.com

この例では、このジョブが実行されるサーバーに NGINX と GitLab Runner がセットアップされている必要があります。

注意:ブランチとレビューアプリの名前に関するエッジケースについては、制限事項のセクションを参照してください。

完成例では、開発者に以下のようなワークフローを提供しています:ローカルにブランチを作成する

ローカルにブランチを作成する
変更を加えてコミットする
GitLabにブランチの変更をプッシュする
マージリクエストを作成する

GitLab Runnerはこれらの裏で次のようなことをしています:

変更をピックアップし、ジョブの実行を開始します
stagesで定義されているように、ジョブを順次実行します：
- まず、テストを実行します
- テストが成功した場合、アプリをビルドします
- ビルドに成功した場合、アプリはブランチに固有の名前を持つ環境にデプロイされます

そして、全てのブランチに以下を行います:

独自の環境を提供する
独自の場所にデプロイする。それによって、以下の利点があります:
- デプロイの履歴を持つことができる
- 必要に応じて、変更をロールバックできる

詳細については、環境の URL を使うを参照してください。

保護された環境

アクセスを制限することにより、環境を”保護”できます。

詳細は、保護された環境を参照してください。

環境の操作

環境が構成されると、GitLabは環境を操作するための多くの機能を提供します。

環境とデプロイメントの表示

環境とデプロイメントの状態の一覧は、各プロジェクトの[オペレーション] > [環境]ページで確認できます。

使用例：

この例では、以下のように表示されます:

環境の名前とそのデプロイメントへのリンク
最後のデプロイメントIDとそれを実行した人
最後のデプロイメントのジョブIDとそれぞれのジョブ名
最後のデプロイメントのコミット情報 (誰がコミットしたのか、どのブランチにコミットしたのか、コミットのGit SHAなど)
最後のデプロイメントが実行された正確な時刻
.gitlab-ci.ymlのenvironment キーワードで定義した URL に移動するボタンです。
最新のデプロイを再デプロイするボタン。つまり、特定のコミットの環境名で定義されたジョブを実行する

環境ページに表示される情報は最新のデプロイメントに限定されますが、一つの環境に複数のデプロイメントを含めることができます。

注:

ウェブインターフェイスで手動で環境を作成することもできますが、最初に.gitlab-ci.yml で環境を定義することをお勧めします。最初のデプロイ後に自動的に環境が作成されます。
環境ページは、Reporter パーミッションを持つユーザーのみが閲覧できます。パーミッションの詳細については、パーミッションのドキュメントを参照してください。
.gitlab-ci.yml が適切に設定された後に行われたデプロイのみが、[環境]リストと [最後のデプロイ] リストに表示されます。

デプロイに関する履歴の表示

GitLabではデプロイの記録を保持します:

現在サーバーに何がデプロイされているかを常に知ることができます
全ての環境に関するデプロイの完全な履歴を持つことができます

環境をクリックすると、その環境のデプロイの履歴が表示されます。以下は、複数のデプロイメントを持つEnvironmentsページの例です:

このビューは環境ページに似ていますが、全てのデプロイメントが表示されます。また、このビューには ロールバック ボタンがあります。詳細については、再試行とロールバックを参照してください。

再試行とロールバック

デプロイで問題が発生した場合に、再試行またはロールバックできます。

デプロイを再試行またはロールバックするには:

Operations > Environmentsを開きます
環境をクリックします
環境のデプロイ履歴リストで下記を実行します:
- 前回の配置の横にある再試行ボタンをクリックして、その配置を再試行します
- 前に配置が成功したときの横にあるロールバックボタンをクリックすると、その配置にロールバックします

ロールバック実施時に期待すること

特定のコミットのロールバックボタンを押すと、独自のジョブIDを持つ 新しい デプロイが起動します。

これは、ロールバック先のコミットを指す新しいデプロイが表示されることを意味します。

注:ジョブのscript で定義されたデプロイプロセスによって、ロールバックが成功するかどうかが決まります。

環境URLを利用する

環境URLはGitLab内で公開されています:

マージリクエストでのリンク:
環境ビューにあるボタン:
デプロイビューにあるボタン:

この情報は、以下の場合にマージリクエスト上で直接確認することができます:

マージリクエストは最終的にデフォルトブランチ (通常はmaster) にマージされます。
そのブランチも環境（たとえば、staging やproduction）にデプロイされます。

使用例：

ソースファイルから公開ページへ

GitLab のルートマップを使うと、ソースファイルからReview Appsに設定されている環境にある公開ページへのアクセスを停止します。

環境の停止

環境を停止する:

Environmentsページにある利用可能な環境リストから停止中の環境リストに移動します
on_stop アクションを実行します。

これは、複数人の開発者が同時に同じプロジェクトでの作業をして、それぞれのブランチにプッシュしている場合によく使われ、多くの動的な環境が作られる原因となります。

Note:GitLab 8.14から、動的環境は関連ブランチが削除されると自動的に停止します。

環境を自動的に停止する

環境は特別な設定を使って自動的に停止させることができます。

deploy_review のジョブがstop_reviewを呼び出して環境をクリーンアップし、停止する例を考えてみましょう：

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review
  only:
    - branches
  except:
    - master

stop_review:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  script:
    - echo "Remove review app"
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop

ブランチが削除された後に GitLab Runnerがコードをチェックアウトしようとしないように、stop_review のジョブでGIT_STRATEGY をnone に設定する必要があります。

停止アクションが定義されている環境がある場合（通常、その環境がレビューアプリを記述している場合）、関連するブランチが削除されると、GitLab は自動的に停止アクションをトリガーします。環境が自動的に停止するためには、stop_review ジョブがdeploy_review ジョブと同じstage にある必要があります。

さらに、両方のジョブはrulesもしくはonly/except の設定が一致している必要があります。上の例で、設定が一致していない場合、stop_review ジョブはdeploy_review ジョブを含むすべてのパイプラインに含まれず、action: stop をトリガーして自動的に環境を停止することができないかもしれません。

詳しくは.gitlab-ci.yml referenceをご覧ください。

環境オートストップ

GitLab 12.8で導入されました。

環境に有効期限を設定し、一定期間経過後に自動的に停止させることができます。

たとえば、レビューアプリ環境でのこの機能の使用について考えてみましょう。レビューアプリをセットアップしたとき、いくつかのマージリクエストが未解決のままになっているために、長い間実行され続けることがあります。このような状況の例として、マージリクエストの作成者が優先順位の変更や別のアプローチが決定されたために積極的に取り組んでおらず、単にマージリクエストが忘れられている場合があります。アイドル環境はリソースを浪費するので、できるだけ早く終了させるべきです。

この問題に対処するために、レビューアプリ環境にオプションで有効期限を指定することができます。有効期限に達すると、GitLabは自動的に環境を停止するジョブをトリガーし、手動で停止する必要がなくなります。環境が更新された場合、有効期限はアクティブなマージリクエストのみがレビューアプリを実行し続けることを保証するために更新されます。

この機能を有効にするには、.gitlab-ci.ymlでenvironment:auto_stop_in キーワードを指定する必要があります。値として、1 hour and 30 minutes や1 dayのように、人にわかりやすい日付を指定することができます。auto_stop_in は、artifacts:expire_in docsと同じ書式を使用します。

注意:リソースの制限のため、環境を停止するバックグラウンドワーカーは1時間に1回しか実行されません。つまり、環境は指定された期間と同じタイムスタンプで停止されるわけではなく、1時間ごとの cron ワーカーが期限切れの環境を検出したときに停止されます。

オートストップの例

次の例では、マージリクエストごとに新しい環境を作成する基本的なレビューアプリがセットアップされています。review_app ジョブはプッシュされるたびに起動し、review/your-branch-nameという名前の環境を作成または更新します。stop_review_app が実行されるまで、この環境は実行され続けます：

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    on_stop: stop_review_app
    auto_stop_in: 1 week

stop_review_app:
  script: stop-review-app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  when: manual

マージリクエストがアクティブで新しいコミットを取得し続けている限り、レビューアプリは停止しません。

一方、stop_review_app はauto_stop_in: 1 weekに設定されているので、マージリクエストが一週間以上非アクティブになると、GitLab は自動的にstop_review_app ジョブをトリガーして環境を停止します。

環境の有効期限はGitLabのUIからも確認することができます。そのためには、オペレーション> 環境 > 環境と進みます。左上のセクションに自動停止期間が表示され、右上のセクションにピンマークのボタンがあります。このピンマークのボタンを使って環境の自動停止を防ぐことができます。このボタンをクリックすると、auto_stop_in の設定が上書きされ、手動で停止させるまで環境がアクティブになります。

停止した環境の削除

GitLab 12.10 で導入されました。

停止した環境を削除するには、GitLab UIかAPIの2つの方法があります。

UIによる環境削除

停止した環境のリストを表示するには、オペレーション> 環境に移動し、[停止した環境]タブをクリックします。

そこから直接削除ボタンをクリックするか、環境名をクリックして詳細を表示し、そこから削除することができます。

停止している環境の詳細を見ることで環境を削除することもできます：

Operations > Environmentsを開きます
停止中の環境リスト内の環境名をクリックします。
停止しているすべての環境の上部に表示される削除ボタンをクリックしてください。
最後に、表示されたモーダルで選択した環境を確認して削除します。

APIによる環境削除

環境は、Environments APIを使用して削除することもできます。

類似環境のグループ化

GitLab 8.14 で導入されました。

動的環境の構成で説明されているように、環境名の前に単語を付け、その後に/を付け、最後にブランチ名を付けることができます。ブランチ名はCI_COMMIT_REF_NAME 変数によって自動的に定義されます。

つまり、type/foo のような名前の環境は、すべてtypeという同じグループで表示されます。

最小限の例では、review/$CI_COMMIT_REF_NAMEという環境名をつけました。$CI_COMMIT_REF_NAME はブランチ名です。以下はそのスニペットです：

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_NAME

この場合、環境ページにアクセスし、ブランチが存在すれば、次のように表示されるはずです：

監視環境

Prometheusでシステムメトリクスとレスポンスメトリクスの監視を有効にしている場合、各環境で実行されているアプリの動作を監視できます。監視ダッシュボードを表示するには、Prometheusで少なくとも1つのサポートされているメトリクスを収集するように設定する必要があります。

Note:GitLab 9.2 以降、環境へのデプロイは全てモニタリングダッシュボードに直接表示されます。

設定が完了すると、GitLab はデプロイに成功した環境に対してサポートされているパフォーマンスメトリクスの取得を試みます。モニタリングデータの取得に成功した場合、各環境に対してMonitoringボタンが表示されます。

モニタリング]ボタンをクリックすると、過去8時間分のパフォーマンスデータを表示する新しいページが表示されます。初期デプロイ後、データが表示されるまで1～2分かかる場合があります。

環境へのすべてのデプロイはモニタリングダッシュボードに直接表示され、GitLabを離れることなく、パフォーマンスの変化とアプリの新バージョンを簡単に相関させることができます。

GitLab Flavored Markdownにメトリクスを埋め込む

メトリクスチャートはGitLab Flavored Markdownに埋め込むことができます。詳しくはGitLab Flavored Markdownにメトリクスを埋め込むをご覧ください。

ウェブ端末

WebターミナルはGitLab 8.15で追加され、プロジェクトのメンテナーとオーナーだけが利用できます。

デプロイサービス（例えばKubernetesインテグレーション）の助けを借りて環境にデプロイする場合、GitLabはあなたの環境へのターミナルセッションを開くことができます。

この機能を有効にするには、サービス・インテグレーション・ドキュメントの指示に従ってください。

有効にすると、あなたの環境には「ターミナル」ボタンが追加されます：

特定の環境のページからターミナルボタンにアクセスすることもできます：

ボタンをクリックすると、ターミナルセッションを確立するための別のページに移動します：

これは他のターミナルと同じように動作します。デプロイによって作成されたコンテナ内にいるので、以下のことができます：

シェルコマンドを実行し、リアルタイムで応答を取得します。
ログを確認してください。
設定やコードの微調整などをお試しください。

同じ環境に複数のターミナルを開くことができ、それぞれ独自のシェルセッションと、screen やtmuxのようなマルチプレクサを利用できます。

注意:コンテナベースのデプロイには基本的なツール（エディタのようなもの）がないことが多く、いつでも停止または再起動される可能性があります。その場合、すべての変更が失われます。これは総合的なオンラインIDEではなく、デバッグツールとして扱ってください。

ローカルでのデプロイチェック

GitLab 8.13以降、Gitリポジトリの参照はデプロイごとに保存されるので、現在の環境の状態を知るにはgit fetch 。

gitの設定で、[remote "<your-remote>"] ブロックに追加のフェッチ行を追加します：

fetch = +refs/environments/*:refs/remotes/origin/environments/*

スペックによる環境構築

GitLab Premium9.4から導入されました。
環境変数のスコープはGitLab 12.2 でCore に移動しました。

変数の環境スコープを制限するには、その変数が利用可能な環境を定義します。

ワイルドカードを使うことができ、デフォルトの環境スコープは*です。これは、環境が定義されているかどうかに関係なく、すべてのジョブがこの変数を持つことを意味します。

例えば、環境スコープがproduction, productionであるproduction場合、その環境が production定義されたproductionジョブのみが productionこの特定の変数を持つことになります。環境名と共にワイルドカード (*) を使用することができます。したがって、環境スコープがreview/* である場合、review/ で始まる環境名を持つすべてのジョブがこの特定の変数を持つことになります。

GitLabの機能の中には、環境ごとに動作が異なるものがあります。例えば、本番環境のみに注入する秘密変数を作成することができます。

ほとんどの場合、これらの機能は_環境仕様の_メカニズムを使用しており、各環境グループ内でスコープを実装する効率的な方法を提供しています。

4つの環境があるとしましょう：

production
staging
review/feature-1
review/feature-2

各環境は、以下の環境仕様に合わせることができます：

環境仕様	`production`	`staging`	`review/feature-1`	`review/feature-2`
*	一致	一致	一致	一致
生産	一致
ステージング		一致
review/*			一致	一致
レビュー/特集-1			一致

ご覧のように、特定のマッチングを使用して特定の環境を選択したり、ワイルドカードマッチング(*)を使用してレビューアプリ(review/*)などの特定の環境グループを選択することができます。

注意：最も_具体的な_仕様が、他のワイルドカードマッチングよりも優先されます。この場合、review/feature-1 の仕様が、review/* と* の仕様よりも優先されます。

環境ダッシュボード

各環境のオペレーション状況の概要については、環境ダッシュボードをご覧ください。

制限事項

environment: nameでは、あらかじめ定義された環境変数のみに制限されています。script 内部で環境名の一部として定義された変数を再利用することはできません。

さらに読む

以下のリンクは興味深いものです：

環境とデプロイメント

環境とデプロイメント

導入

環境設定

環境の定義

環境変数, Runner

ジョブ終了後に動的環境の URL を設定する

動的環境URLの設定例

手動デプロイメント設定

動的環境の設定

使用可能な変数

設定例

Kubernetesデプロイメントの設定

インクリメンタルロールアウト設定

デプロイメントの安全性

完成例

保護された環境

環境の操作

環境とデプロイメントの表示

デプロイに関する履歴の表示

再試行とロールバック

ロールバック実施時に期待すること

環境URLを利用する

ソースファイルから公開ページへ

環境の停止

環境を自動的に停止する

環境オートストップ

オートストップの例

停止した環境の削除

UIによる環境削除

APIによる環境削除

類似環境のグループ化

監視環境

GitLab Flavored Markdownにメトリクスを埋め込む

ウェブ端末

ローカルでのデプロイチェック

スペックによる環境構築

環境ダッシュボード

制限事項

さらに読む

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