「その修正、本番で見ていい？」をゼロにする。GitLab Review Appsで実現する、爆速フィードバックの極意
こんにちは。現場で数々の泥沼化した開発現場を救ってきた、DevOpsエンジニアです。
皆さんは「フロントエンドのこのボタン、デザインと違う気がする…」「QA環境にデプロイするまで時間がかかる…」といった問題に頭を抱えたことはありませんか？
多くのチームが「マージ→デプロイ→確認」という重たいサイクルを回していますが、これからの時代、そのやり方は「死」を意味します。
今日は、GitLabの神機能である「Review Apps」を使い、MR（マージリクエスト）を作成するたびに、あなた専用の動的プレビュー環境を爆速で立ち上げる方法を伝授します。これを導入すれば、非エンジニアやデザイナーも即座に実機で検証でき、あなたのチームの開発速度は劇的に変わります。
—
1. Review Appsとは何か？：動的な「分身」環境
Review Appsは、ブランチごとに一時的なプレビュー環境を自動で構築する仕組みです。
- 役割: MRごとに独自のURL（例: `feature-login-123.example.com`）を発行する。
- メリット: 非エンジニアが「今の作業中の状態」をワンクリックで確認できるため、認識の齟齬がその場で消滅する。
「動くもの」を見せること以上のコミュニケーションはありません。仕様書を読むより、1分間プレビューを触ってもらうほうが、100倍効率的です。
—
2. 最短で導入する：`.gitlab-ci.yml` の極意
Review Appsを構築するには、CI/CDパイプラインに「環境のデプロイ」と「環境の停止」の2つのジョブを記述するだけです。
今回は、KubernetesやDocker環境を想定した、最も堅牢で汎用的な構成を紹介します。
.gitlab-ci.yml
1. 動的環境のデプロイ
deploy_review:
stage: deploy
script:
- echo “Deploying to ${CI_COMMIT_REF_SLUG}…”
- ./deploy_to_cluster.sh –branch $CI_COMMIT_REF_NAME
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_COMMIT_REF_SLUG.example.com
# ここが重要！MR画面に自動で「View App」ボタンが現れます
on_stop: stop_review
rules:
- if: $CI_PIPELINE_SOURCE == “merge_request_event”
2. ブランチ削除時の自動クリーンアップ
stop_review:
stage: deploy
script:
- echo “Cleaning up ${CI_COMMIT_REF_SLUG}…”
- ./cleanup_cluster.sh –branch $CI_COMMIT_REF_NAME
environment:
name: review/$CI_COMMIT_REF_NAME
action: stop
rules:
- if: $CI_PIPELINE_SOURCE == “merge_request_event”
when: manual # MRマージ時や手動トリガーでクリーンアップ
この設定のポイント
- `environment` ブロック: GitLabが「これは動的環境である」と認識するための魔法の呪文です。
- `on_stop`: これを指定することで、MRを閉じた瞬間に環境を自動破棄できます。「使わない環境でクラウド代が爆上がり」という悲劇を未然に防ぐ必須の設定です。
—
3. Hello World的・動作確認のステップ
まずは複雑な構成にせず、以下の3ステップで「動くこと」を確認しましょう。
1. 環境変数の設定: GitLabの `Settings > CI/CD > Variables` に、デプロイ先（K8sの認証情報やサーバーのSSHキーなど）を登録します。
2. MRを作成: ローカルでブランチを切って、適当な修正をしてプッシュし、MRを開いてください。
3. 確認: パイプラインが走りきると、MRのトップ画面に「View app」という青いボタンが自動生成されます。これをクリックして、あなたの修正がブラウザに表示されれば成功です！
—
4. チーム開発を劇的に変える「運用のコツ」
ツールを入れるだけでは現場は変わりません。以下の運用ハックを共有してください。
- デザイナーを招待する: MRのURLをチャットツールに貼り付ける際、「Figmaのデザインとズレがないか確認お願いします！」と一言添える。これで手戻りが激減します。
- QA環境の共有: エンジニアがテストコードを書く前に、QA担当者がこのURLを見て「ここ、こういう挙動がいい」とフィードバックをくれるようになります。
- 環境変数の分離: プレビュー環境では、本番のDBではなくMock APIやダミーデータを使うように構成しましょう。これにより、セキュリティリスクを抑えつつ爆速で検証できます。
—
最後に：完璧を目指さない勇気
Review Appsを導入する目的は、「完璧な環境を作ること」ではなく、「フィードバックの回数を増やすこと」です。
最初は不安定なこともありますが、GitLabのパイプラインは失敗してもすぐに再実行できます。失敗を恐れず、どんどん動的なプレビュー環境を使い倒してください。
このサイクルを回せるようになれば、あなたのチームは「仕様書通りに作ってから怒られる」苦しみから解放され、「作っている最中に合意を作る」プロフェッショナルなチームへと進化します。
さあ、次のコミットから、プレビュー環境を皆の目に触れさせてみましょう。世界が変わるはずですよ。