GitLabの真価を解放せよ：EnvironmentとReview Appsで構築する「失敗しない」デリバリー戦略
GitLabを単なる「Gitホスティング」や「適当なCIツール」として使っているなら、あなたはフェラーリで近所のスーパーへ買い物に行っているようなものだ。
GitLabの真髄は、「コードからデプロイまでを一つのコンテキストで完結させる」ことにある。特に`Environment`と`Review Apps`を使いこなせば、リリース当日の「動かない！」という絶望を、開発サイクルの日常的なチェックへと変貌させられる。
今回は、DevOpsの現場で「GitLabを使い倒している」と胸を張るための、極限の構成術を伝授する。
—
1. Review Apps：マージ前に「動く環境」を自動生成せよ
多くのチームは、ステージング環境が一つしかなく、デプロイの順番待ちで時間を浪費している。Review Appsは、ブランチごとにEphemeral（一時的）な環境を自動生成する機能だ。
実践的な `.gitlab-ci.yml` 構成例
Review Appsを成功させる鍵は、環境のクリーンアップにある。これがないと、クラウドのコストが爆発する。
.gitlab-ci.yml
stages:
- review
- deploy
Review Appの定義
review_app:
stage: review
script:
- kubectl apply -f k8s/ # 動的にNamespaceを生成してデプロイ
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_COMMIT_REF_SLUG.example.com
on_stop: stop_review_app # ブランチ削除時に自動実行される
rules:
- if: $CI_PIPELINE_SOURCE == “merge_request_event”
stop_review_app:
stage: review
script:
- kubectl delete namespace $CI_COMMIT_REF_SLUG
when: manual # 念のため手動実行を残すが、基本はon_stopで自動化
environment:
name: review/$CI_COMMIT_REF_SLUG
action: stop
ここがプロの視点:
`on_stop`アクションを定義せよ。ブランチがマージされた瞬間にインフラも破棄する。この「エフェメラルであること」こそが、環境の汚染を防ぐ唯一の解だ。
—
2. Environmentダッシュボードによる可視化と制御
GitLabの「Operations > Environments」画面を見ているか？ ここはリリース管理のコントロールタワーだ。
- 誰が・いつ・何を・どこにデプロイしたかが一目でわかる。
- Deployment Approval（承認フロー）：`when: manual` を活用せよ。`protected environments`を設定し、本番環境へのデプロイにはマネージャーやリードエンジニアの承認を必須にする。
現場で役立つ「設定の共有化」ルール
大規模開発では、個々のリポジトリにCIを書かせると惨劇が起きる。
- CIテンプレートの共通化: `include: – project: ‘devops/ci-templates’` を徹底し、全リポジトリでデプロイの作法を統一せよ。
- Variablesの権限管理: CI/CD変数には必ず「Masked（非表示）」と「Protected（保護）」を適用する。漏洩は論外だ。
—
3. 開発スピードを加速させる「裏技」テクニック
隠れたキーボードショートカット
ブラウザ版GitLabで以下のキーを押せ。これを知っているだけで生産性が数倍変わる。
- `g` + `i` : Issuesの一覧へ即ジャンプ
- `g` + `m` : Merge Requestsの一覧へ即ジャンプ
- `Ctrl/Cmd + Enter` : コメントやMRの即時送信（マウス操作は排除せよ）
生産性を底上げする「神プラグイン/ツール」
1. GitLab Workflow (VS Code拡張): VS Codeを離れるな。MRの作成、パイプラインのステータス確認、Review AppのURLへのアクセスがすべてエディタ内で完結する。
2. glab (GitLab CLI): コマンドラインから全てを操作せよ。`glab mr create` でMRを出し、`glab ci view` でログを追う。GUIをポチポチしている時間は現代のエンジニアにはない。
—
4. チームへの導入・定着の極意
「環境を自動構築する」という概念は、ジュニアエンジニアには少し高い壁かもしれない。以下のステップで浸透させろ。
1. まず「可視化」から: 何も自動化せずとも、Environment機能だけを使って「誰がどこにデプロイしているか」を全員が見えるようにする。
2. 次に「自動テスト」を挟む: 手動デプロイにテスト結果をリンクさせる。
3. 最後に「自動デプロイ」: Review Appsを導入し、開発者が「自分のコードが即座に動く」喜びを体感させる。
—
最後に：DevOpsは「ツール」ではなく「カルチャー」だ
GitLabの機能は強力だが、それを支えるのは「デプロイの頻度を最大化し、失敗のコストを最小化する」というエンジニアの哲学だ。
Review Appsで動く環境をチームに見せ、MRの承認ボタンを押し、リリースが成功した瞬間に「おめでとう」と言い合う。その文化を作ることこそが、テックリードの最大の仕事である。
今日から、リポジトリの `.gitlab-ci.yml` を開き、最初の `environment` を定義することから始めてほしい。あなたのCI/CDは、まだ進化できる。