GitLab Pagesから一時共有URLへ切り替えるタイミング

できること

GitLab PagesはMerge Requestにプレビュー環境を自動で生成するReview Apps機能と組み合わせることができます。MRを作成すると専用のプレビューURLが生成され、MRがクローズされると自動で削除されます。コードレビューと視覚的なデザイン確認を同一フローで完結させられる点は、開発チーム内の効率化に大きく貢献します。

GitLab CI/CDのスケジュール機能を使えば、夜間や週次で自動デプロイを止めることも可能です。ただしこれはPagesの停止ではなくビルドジョブのスキップであり、すでに公開されているPagesのURLは生き続けます。

• 相手がログインなしで開ける状態か確認する
• PCとスマホで最低1回ずつ表示を確認する
• 内部情報・個人情報・不要な外部送信が残っていないか見る
• レビュー期限と修正時の差し替え方を決めておく

できないこと

GitLab PagesのReview AppsはMRに紐付いているため、MRをクローズすると環境も削除されます。これはMRベースのフローには便利ですが、クライアントへの提出後に「MRをマージしたらURLが消えた」という事態が起きると、フィードバックの途中でレビュアーがアクセスできなくなります。

また、GitLab Pagesには「このURLは○月○日まで有効」という期限表示をエンドユーザーに見せる機能がありません。クライアントが期限を知るにはURLを送った際のメール等での案内に頼るしかなく、期限の意識が薄れやすいです。

認証と期限の違い

GitLab PagesのAccess Controlは「GitLabアカウントを持つメンバーのみ」という認証です。社外クライアントにGitLabアカウントを要求せずに認証をかけることはできません。これが社外レビューへの切り替えタイミングを考える際の最大の制約です。

認証付き一時共有URLサービスは、GitLabアカウントと無関係に動作します。パスワード・メール・会社ドメインの3種類の認証から選べ、期限も日単位で設定できます。「MRがmainにマージされてビルドが完了したら、その成果物をギガサイト便でクライアントに送る」というフローを設けることで、GitLab Pagesと役割を明確に分けられます。

• 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
• 特定の相手だけ: パスワードまたはメール認証を使う
• 会社内だけ: 会社ドメイン認証を検討する
• 短期レビュー: 期限を設定して古いURLを残さない

差し替え・レビュー運用

GitLab Pagesでの差し替えはパイプラインのトリガーが必要です。セルフホスト環境でランナーが少ない場合、ビルドのキューに並んで反映に時間がかかることがあります。クライアントとリアルタイムに修正確認を行う「オンライン打ち合わせ中の即修正反映」には向かない場合があります。

一時共有URLへの切り替えは「社内承認が終わり、クライアントへ正式提出するタイミング」です。それまでのフェーズはGitLab Pagesで開発・社内確認を行い、提出直前にビルド成果物をZIP化して認証付きURLを発行します。これにより開発フローの継続性を保ちつつ、外部提出だけセキュリティを担保できます。

• 確認してほしい観点を3つ以内に絞る
• 期限と返信先を明記する
• 修正後も同じURLで見られるか伝える
• 最終版と途中版が混ざらないようタイトルを付ける

向いているケース早見表

GitLab Pagesが最適なのは、MRごとのプレビュー自動生成・開発チーム内の視覚確認・GitLabアカウントを持つ社内スタッフや長期パートナー企業との継続的なレビューです。セルフホストGitLabをイントラネットで運用している場合、アクセスが社内ネットワークに限定されるためセキュリティ上の懸念が小さくなります。

一時共有URLへの切り替えが適切なのは、GitLabアカウントを持たないクライアントへの正式提出・期限付きの承認フロー・プロジェクト終了後に自動でURLを失効させたい、というケースです。ギガサイト便はGitLabと独立しているため、GitLabの設定を一切変えずに外部共有のセキュリティを確保できます。