こんにちは！日々のデプロイ作業や「この機能、どの環境に今入ってるんだっけ？」という確認に、頭を悩ませていませんか？
今回は、GitLabが持つ強力な機能「Environment（環境）」と「Deployment（デプロイメント）」、そして開発体験を爆発的に向上させる「Review Apps（レビューアプリ）」について、徹底的に解説していきます。
これをマスターすれば、あなたのチームのリリース管理は劇的に変わり、毎日の作業が驚くほど楽になりますよ。さあ、一緒にモダンなCI/CDの世界へ飛び込みましょう！
—
1. なぜGitLabのEnvironment機能を使うべきなのか？
開発が進むにつれて、こんな課題にぶつかったことはありませんか？
- 「今、ステージング環境にあるのはどのブランチのコードだっけ？」
- 「本番環境へのリリースボタンを押すのが怖すぎる…」
- 「プルリクエストごとに動く確認用環境が欲しいけど、構築やメンテが面倒…」
GitLabの Environment は、CI/CDパイプライン（`.gitlab-ci.yml`）からデプロイ先を定義・追跡するための機能です。これを使うと、「どのコミットが、どの環境に、いつデプロイされたのか」がGitLab上で一目瞭然のダッシュボードとして可視化されます。
さらに、Review Appsを組み合わせれば、「マージリクエストごとに自動で一時的な確認用URLが生え、マージされたら勝手に消える」という、夢のような開発フローが手に入ります。
—
2. 基礎セットアップ：Environmentを使ってみよう
まずは最もシンプルな形として、ステージング環境への自動デプロイと、GitLabでの可視化を設定してみましょう。
`.gitlab-ci.yml` の基本形
GitLab CI/CDでEnvironmentを使うには、ジョブの中に `environment` キーを記述するだけです。これだけで、GitLabがそのデプロイを追跡し始めます。
stages:
- deploy
ステージング環境へのデプロイジョブ
deploy_staging:
stage: deploy
image: alpine:latest
script:
- echo “ステージング環境へデプロイしています…”
# 実際のデプロイコマンド（Kubernetes, SSH, クラウドへの転送など）をここに書きます
- echo “Deployment completed successfully!”
environment:
name: staging # 環境の名前（ダッシュボードでグループ化されます）
url: https://staging.example.com # 実際の環境にアクセスするためのURL
only:
- develop # developブランチがプッシュされたら実行
たったこれだけの設定で、GitLabの [Deployments] > [Environments] メニューを開くと、`staging` という環境が作成され、最新のデプロイ状況やURLが綺麗に表示されるようになります。
—
3. 【実践】Review Appsでプルリクごとの「動く確認環境」を爆誕させる
ここからが本番です。機能開発のたびに「確認用環境」を自動で立ち上げる Review Apps を設定しましょう。
Review Appsの肝は、動的な環境名（Dynamic Environments）と、環境が不要になったときの自動クリーンアップ（Stop行動）です。
Review Appsの全体像
1. ブランチ作成・プッシュ: 特徴的なURL（例: `feature-login-xyz.review.example.com`）で環境が自動構築される。
2. レビュー: チームメンバーがURLをクリックして実際の動きを確認する。
3. マージまたはクローズ: ブランチが消えたりマージされたりすると、環境が自動で破棄（Stop）される。
Review Apps対応の `.gitlab-ci.yml` サンプル
stages:
- deploy
- cleanup
1. Review Appのデプロイ（コードがプッシュされたとき）
deploy_review:
stage: deploy
image: docker:stable
script:
- echo “動的なReview Appを構築中… ブランチ名: $CI_COMMIT_REF_SLUG”
- echo “URL: https://$CI_COMMIT_REF_SLUG.review.example.com”
# ここでDockerやK8sなどを使ってプレビュー環境をデプロイするスクリプトを実行
environment:
name: review/$CI_COMMIT_REF_SLUG # ブランチ名ごとにユニークな環境名を作る
url: https://$CI_COMMIT_REF_SLUG.review.example.com
on_stop: stop_review # ブランチ削除時や手動停止時に呼ぶジョブを指定
except:
- main
- develop
2. Review Appの停止（ブランチが削除されたり、手動で止めたりしたとき）
stop_review:
stage: cleanup
image: alpine:latest
script:
- echo “Review Appを停止してリソースを解放します: $CI_COMMIT_REF_SLUG”
# ここで環境を破棄するスクリプトを実行
environment:
name: review/$CI_COMMIT_REF_SLUG
action: stop # これによりGitLab上で環境が「停止状態」になる
when: manual # 自動削除せず手動ボタンを残したい場合は manual にする（自動化なら行ごと削除）
except:
- main
- develop
この設定を行うと、GitLabのマージリクエスト画面に「View app」というボタンが自動で出現します。レビュワーはコードを見ながらワンクリックでそのブランチの動作確認ができるため、レビュー速度が何倍にも跳ね上がります。
—
4. 本番リリースを守る：デプロイ承認フロー（Manual & Protected Environments）
ステージングやReview Appsで十分にテストができたら、いよいよ本番環境へのリリースです。
本番環境へのデプロイは、誰でもいつでも押せてしまっては困りますよね。GitLabの機能を使って、「特定の権限を持つ人だけが、承認ボタンを押した時だけデプロイされる」安全な仕組みを作りましょう。
1. Protected Environments（保護された環境）の設定
GitLabのプロジェクト設定から、本番環境（例: `production`）を保護します。
- Settings > CI/CD > Protected environmentsを開く
- Environment name に `production` を指定
- Allowed to deploy（デプロイを許可するロールやユーザー）を、管理者（Maintainer）や特定のデプロイ用ユーザーだけに制限します。
2. パイプラインでの手動承認設定（`when: manual`）
deploy_production:
stage: deploy
image: alpine:latest
script:
- echo “本番環境へのデプロイを実行中…”
- ./deploy-to-prod.sh
environment:
name: production
url: https://example.com
when: manual # ★ここがポイント：パイプラインが一時停止し、手動クリックを待つ
only:
- main
この設定を入れると、`main` ブランチにマージされてビルドが成功した後も、「誰かがGitLabの画面上で『Play』ボタンを押すまで」デプロイが一時停止します。さらに、Protected Environmentsの設定により、権限を持たないメンバーにはそのボタンすら表示されません。これで、誤爆による本番障害を完全に防ぐことができます。
—
まとめ：GitLabで「見通しの良い開発」を手に入れよう
今回は、GitLabのEnvironment機能を中心に、以下のポイントをご紹介しました。
1. Environment機能で、どの環境に何があるかをダッシュボードで完全可視化する。
2. Review Appsを使って、マージリクエストごとに動的な確認用環境を自動生成・破棄する。
3. Protected Environmentsと `when: manual` を組み合わせて、安心・安全な本番リリースフローを作る。
これらを導入することで、「いまどうなっているんだっけ？」というチーム内の無駄なコミュニケーションや、リリース時の不安が嘘のように消え去ります。
明日からの開発に、ぜひ一つずつ取り入れてみてください。あなたのチームのCI/CDが、もっと楽しく、もっと強力なものになることを応援しています！