GitLab Review Apps：非エンジニアを「開発の共犯者」にするための極限最適化術
「またデザインと実装の齟齬で手戻りか……」
「QA環境が空くのを待っていて、デプロイがボトルネックになっている」
そんな悩みを抱えているテックリードの諸君。GitLabのReview Appsは単なる「おまけ機能」ではない。これは、開発サイクルそのものを非同期・並列化し、フィードバックループの時間をゼロに近づけるための最強の兵器だ。
本稿では、Review Appsを単に「動くURLが出る」というレベルから、「非エンジニアが自律的にフィードバックを投げ込める最強の協働プラットフォーム」へと昇華させるための実践的ノウハウを伝授する。
—
1. Review Appsの真髄：ただのプレビューで終わらせない
Review Appsの目的は、コードの検証ではない。「意図した体験が実現されているか」をステークホルダーと即座に同期することにある。
現場で「刺さる」Review Appsの構成
ただプレビューを出すのではなく、以下の要素を組み合わせるのがプロの作法だ。
- URLの即時共有: MR（Merge Request）のコメントに自動でリンクを投稿。
- デザインとの直結: FigmaのプロトタイプリンクをMRのヘッダーに埋め込む。
- 環境クリーンアップ: 放置するとAWS/GCPのコストを食いつぶす「ゾンビ環境」を確実に滅する。
—
2. 実践的 `.gitlab-ci.yml` 構成術
Review Appsを運用する上で、最も重要なのは「冪等性」と「ライフサイクル管理」だ。以下の構成は、多くの現場で採用されている堅牢なテンプレートである。
.gitlab-ci.yml
stages:
- build
- review
- cleanup
Review Appのデプロイジョブ
deploy_review:
stage: review
script:
- ./scripts/deploy_to_k8s.sh –branch $CI_COMMIT_REF_SLUG
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_COMMIT_REF_SLUG.example.com
# ここが重要：MRクローズ時に自動で削除をトリガーする設定
on_stop: stop_review
rules:
- if: $CI_PIPELINE_SOURCE == “merge_request_event”
環境のクリーンアップジョブ
stop_review:
stage: cleanup
script:
- ./scripts/delete_from_k8s.sh –branch $CI_COMMIT_REF_SLUG
when: manual # 手動、またはMRクローズ時に自動実行させる
environment:
name: review/$CI_COMMIT_REF_SLUG
action: stop
rules:
- if: $CI_PIPELINE_SOURCE == “merge_request_event”
現場を救う「隠れた」テクニック
- 環境変数の活用: `$CI_COMMIT_REF_SLUG` を使うことで、ブランチごとにユニークなサブドメインを自動生成せよ。
- TTL付きのデプロイ: K8sのNamespaceに `app-expire-at` ラベルを付与し、Cronジョブで「作成から48時間経過した環境」を自動削除するスクリプトを走らせるのが、クラウド破産を防ぐ鉄則だ。
—
3. 非エンジニアを巻き込む「フィードバックUI」のハック
エンジニア以外は「どこに何を報告すればいいか」で迷う。そこで以下の施策を打つ。
1. 「フィードバックボタン」の埋め込み:
Review Appの中に、Google FormsやBacklogのURLを埋め込んだ小さなUIをオーバーレイさせる。「バグ報告・デザイン確認はこちら」と明記するだけで、フィードバックの質が劇的に向上する。
2. GitLabの「Review Appリンク」をSlackに飛ばす:
`chatops` を使って、MR作成時にSlackチャンネルへ「プレビュー環境が準備できました：[URL]」と通知を飛ばす。これだけで、PMやデザイナーは「いちいちGitLabを見に行かなくていい」という体験を得られる。
—
4. テックリードが愛用する「神」ツール＆設定
開発スピードを加速させるキーボードショートカット
- `g` → `m`: GitLabのMR一覧へ即座にジャンプ。
- `g` → `i`: Issue一覧へ。
- `Shift` + `/`: コマンドパレットを開く（これが最強。ファイル検索や設定変更を爆速で行える）。
絶対に入れるべきブラウザ拡張
- [GitLab Tree Navigator](https://chrome.google.com/webstore/category/extensions): MR画面でファイルツリーを表示する。巨大なリポジトリのレビュー時間を半分にする必須ツール。
チーム開発における「暗黙知」をルール化する
- `CODEOWNERS` の徹底: レビューが必要なパス（例: `/design-tokens/`）には必ずデザイナーをアサインするよう強制する。
- MRテンプレートの活用: MR作成時に「プレビュー環境のURL」を自動挿入するテンプレートを定義せよ。
🎯 変更の目的
…
🚀 プレビュー環境
- [ ] [Review Appはこちら](https://${CI_COMMIT_REF_SLUG}.example.com)
🎨 デザイン確認 (Figma)
- [ ] [Figmaリンクをここに配置]
—
5. 最後に：ツールの向こう側にある「文化」
Review Appsは単なる自動化ツールではない。「エンジニアが書いたコードが、即座に動く姿となって周囲の目に触れる」という文化を醸成する装置だ。
コードを書いてからリリースされるまで、誰も内容を知らない——そんな時代は終わった。
Review Appsを導入し、PMもデザイナーもQA担当者も、皆が同じURLを見て、同じ言語で語り合う。その先にあるのは、手戻りのない、圧倒的な速度で進化し続けるプロダクト開発だ。
さあ、今すぐ設定ファイルを開き、最初の `environment` を定義しよう。君のチームの生産性が、今日から変わる。