GitLab開発におけるレビューアプリの利用

レビューアプリはstart-review-app-pipeline ジョブを使ってデプロイします。このジョブは、レビューアプリのデプロイに必要なさまざまなタスクを実行する一連のジョブを含む子パイプラインをトリガーします。

start-review-app-pipeline job

以下のシナリオでは、start-review-app-pipeline のジョブが自動的に開始されます：

  • CI 設定の変更を伴うマージリクエストの場合
  • フロントエンドの変更を含むマージリクエストの場合
  • への変更を含むマージリクエストの場合{,ee/,jh/}{app/controllers}/**/*
  • への変更を含むマージリクエストの場合{,ee/,jh/}{app/models}/**/*
  • への変更を含むマージリクエストの場合{,ee/,jh/}lib/{,ee/,jh/}gitlab/**/*
  • QA 変更を含むマージリクエストの場合
  • スケジュールパイプライン用
  • MRはpipeline:run-review-app ラベルが設定されています。

レビューアプリのE2Eテスト実行

qa ステージ (review ステージの後) のすべてのパイプラインで、review-qa-smoke とreview-qa-blocking のジョブが自動的に開始されます。

qa ステージは以下のジョブで構成されています：

  • review-qa-smokeGitLabのコア機能を検証するための、小規模で迅速なテストのサブセット。
  • review-qa-blocking信頼できるテストのサブセット。これらのテストは安定しているとみなされ、失敗は許されません。
  • review-qa-non-blocking手動でトリガーできる残りの e2e テスト。

review-qa-* ジョブは、マージリクエストの変更に対するエンドツーエンドのテストが本番環境でパスすることを保証します。これは、GitLab.comの機能を壊したり、コストのかかるGitLab.comのデプロイ・ブロッカーを防いだりするために、e2eの失敗の特定を本番環境からマージリクエストにシフトします。必要であれば review-qa-*、エラーの根本的な原因を特定するために、SET（テスト中のソフトウェア・エンジニア）と一緒にエラーを調査する必要があります。

エンドツーエンドのテスト実行が終わると、e2e-test-report ジョブによってAllure レポートが生成・公開されます。レポートへのリンクを含むコメントがマージリクエストに追加されます。

エラーはgitlab-review-apps Sentry プロジェクトで見つけることができ、レビューアプリの URLやコミット SHAでフィルタリングできます。

失敗したレビューアプリのデプロイをバイパスして、壊れたmaster の修正をマージします。

レビューアプリのデプロイの失敗によってパイプラインがブロックされ、顧客にとって重要なマージリクエストがブロックされた場合、メンテナーはmaster](https://about.gitlab.com/handbook/engineering/workflow/#instructions-for-the-maintainer) が壊れている間のマージに[プロセスを使用することを選択できます。

パフォーマンスメトリクス

qa ステージのすべてのレビューアプリの子パイプラインで、browser_performance ジョブが自動的に開始されます。このジョブはSitespeed.io コンテナを使用して基本的なブラウザのパフォーマンステストを行います。

レビューアプリのサンプルデータ

レビューアプリをデプロイすると、sample-gitlab-project テンプレートプロジェクトからプロジェクトデータが作成されます。これは、手動テストや探索的テストを容易にするために、あらかじめ入力されたリソースをプロジェクトに提供することを目的としています。

サンプルプロジェクトはroot ユーザーネームスペースに作成され、そのユーザーの個人プロジェクトリストからアクセスできます。

サンプル・プロジェクトの作成方法

レビューアプリをまっさらな状態から再デプロイする方法

レビューアプリをリセットし、まっさらな状態から再デプロイするには、以下の手順を実行します：

  1. review-stop ジョブを実行します。
  2. review-deploy ジョブを実行または再試行してデプロイを再実行します。

こうすることで、以前にデプロイされたレビューアプリから既存のデータがすべて削除されます。

GCPレビューアプリクラスターへのアクセスを取得します。

gcp-review-apps-dev GCPグループとロールのアクセスリクエスト（内部リンク）を開く必要があります。

これにより、以下の権限が付与されます：

私のレビューアプリにログインします。

GitLabチームメンバー専用です。レビューアプリにサインインしたい場合は、共有1PasswordアカウントのGitLabハンドブック情報をレビューしてください。

  • デフォルトのユーザー名はroot です。
  • パスワードは、GitLab EE Review App という 1Password ログイン項目にあります。

レビューアプリの機能フラグを有効にします。

  1. レビューアプリを開き、上記の手順でサインインします。
  2. 個人アクセストークンを作成します。
  3. 機能フラグAPIを使用して機能フラグを有効にします。

レビューアプリのスラッグを探す

  1. review-deploy ジョブを開きます。
  2. ** Deploying review-* を探してください。
  3. 例えば** Deploying review-1234-abc-defg... ** の場合、レビューアプリのスラッグはreview-1234-abc-defg になります。

Railsコンソールを実行します。

  1. まずクラスターへのアクセス権限とcontainer.pods.exec 権限があることを確認してください。
  2. レビューアプリのスラッグでワークロードをフィルタリングします。たとえば、review-qa-raise-e-12chm0 。
  3. toolbox デプロイを見つけて開きます。たとえば、review-qa-raise-e-12chm0-toolbox 。
  4. Managed pods」セクションでポッドを選択します。たとえば、review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz 。
  5. KUBECTL ドロップダウンリストを選択し、Exec ->toolbox.
  6. デフォルトのコマンドから-c toolbox -- ls を-it -- gitlab-rails console に置き換えるか、または
    • kubectl exec --namespace review-qa-raise-e-12chm0 review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz -it -- gitlab-rails console を実行し
      • review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz をあなたのポッドの名前に置き換えてください。

ポッドのログを調べる

  1. まずクラスターへのアクセス権限とcontainer.pods.getLogs 権限があることを確認してください。
  2. レビューアプリのスラッグでワークロードをフィルタリングします。たとえば、review-qa-raise-e-12chm0 。
  3. migrations デプロイを見つけて開きます。たとえば、review-qa-raise-e-12chm0-migrations.1 。
  4. Managed pods」セクションでポッドを選択します。たとえば、review-qa-raise-e-12chm0-migrations.1-nqwtx 。
  5. Container logs を選択します。

あるいは、ログを検索するためのより多くのユーティリティを提供するログエクスプローラを使用することもできます。ポッド名のクエリの例は次のとおりです：

resource.labels.pod_name:"review-qa-raise-e-12chm0-migrations"

どのように動作しますか？

CI/CDアーキテクチャ図

graph TD A["build-qa-image, compile-production-assets<br/>(canonical default refs only)"]; B1[start-review-app-pipeline]; B[review-build-cng]; C["review-deploy<br><br>Helm deploys the review app using the Cloud<br/>Native images built by the CNG-mirror pipeline.<br><br>Cloud Native images are deployed to the `review-apps`<br>Kubernetes (GKE) cluster, in the GCP `gitlab-review-apps` project."]; D[CNG-mirror]; E[review-qa-smoke, review-qa-blocking, review-qa-non-blocking<br><br>gitlab-qa runs the e2e tests against the review app.]; A --> B1 B1 --> B B -.->|triggers a CNG-mirror pipeline| D D -.->|depends on the multi-project pipeline| B B --> C C --> E subgraph "1. gitlab-org/gitlab parent pipeline" A B1 end subgraph "2. gitlab-org/gitlab child pipeline" B C E end subgraph "CNG-mirror pipeline" D>Cloud Native images are built]; end

詳細説明

  1. prepare ステージ中のすべてのパイプラインで、compile-production-assets ジョブが自動的に開始されます。
    • それが完了すると、review-build-cng ジョブが開始します。これは、次のステップでトリガーされるCNG-mirror パイプラインがそれに依存しているからです。
  2. compile-production-assets が終了すると、review-build-cng ジョブはCNG-mirror プロジェクトのパイプラインをトリガーします。
    • review-build-cng ジョブは、MRにCIやフロントエンドの変更が含まれている場合にのみ自動的に開始されます。それ以外の場合、ジョブは手動です。
    • CNG-mirror パイプラインは、GitLab パイプラインからのコミットに基づいて各コンポーネントの Docker イメージ（例えば、gitlab-rails-ee,gitlab-shell,gitaly など）を作成し、レジストリに保存します。
    • CNG, (Cloud Native GitLab)のプロジェクトのレジストリに多くの一時的なDockerイメージが過負荷にならないように、CNG-mirror プロジェクトを使用しています。
  3. review-build-cng が完了すると、review-deploy ジョブは公式の GitLab Helm チャートを使ってレビューアプリを GCP 上のreview-apps Kubernetes クラスターにデプロイします。
  4. review-deploy ジョブが成功すると、MR ウィジェットからの直接リンクにより、レビューアプリを使用できるようになります。レビューアプリにログインするには、以下の “Log into my review app?” を参照してください。

その他の注意事項

  • review-deploy ジョブが失敗し続ける場合（手動で再試行してもうまくいかない場合）、#g_qe_engineering_productivity チャンネルにメッセージを投稿するか、マージリクエストへのリンクを含む~"Engineering Productivity" ~"ep::review apps" ~"type::bug" イシューを作成してください。デプロイの失敗によって、マージリクエストで導入された実際の問題が明らかになる可能性があります（つまり、これは必ずしも一過性の失敗ではありません）！
  • review-qa-smoke またはreview-qa-reliable のジョブが失敗し続ける場合 (すでに一度再試行しています)、ジョブのログを確認してください: あなたのマージリクエストで導入された実際の問題を発見できるかもしれません。失敗が発生したページのスクリーンショットを見るためにアーティファクトをダウンロードすることもできます。もし失敗の原因が見つからなかったり、あなたの変更と関係なさそうな場合は、#quality チャンネルにメッセージを投稿するか、あなたのマージリクエストへのリンクを添えて ~Quality ~"type::bug" issue を作成してください。
  • 手動review-stop はレビューアプリを手動で停止するために使うことができます。また、マージリクエストのブランチがマージ後に削除されると、GitLab によって開始されます。
  • Kubernetes クラスターは、GitLab Kubernetes インテグレーションを使ってgitlab プロジェクトに接続されています。これにより、基本的にマージリクエストウィジェットから直接レビューアプリへのリンクを持つことができます。

レビューアプリの自動停止

環境自動停止機能により、レビューアプリは最後のデプロイから2日後に自動的に停止します。

レビューアプリを長時間立ち上げておく必要がある場合は、その環境を固定するか、review-deploy ジョブを再試行して “latest deployed at” 時間を更新することができます。

スケジュールされたパイプラインで自動的に実行されるreview-cleanup ジョブは、5日後に古いレビューアプリを停止し、6日後にその環境を削除し、7日後にぶら下がっている Helm リリースと Kubernetes リソースをクリーンアップします。

クラスターの設定

クラスターはengineering-productivity-infrastructure プロジェクトの Terraform 経由で設定します。

GitLab RunnerのKubernetes Executorには既知のイシューがあるため、ノードプールのイメージタイプはContainer-Optimized OS with Containerd (cos_containerd) ではなくContainer-Optimized OS (cos) である必要があります。

Helm

使用される Helm のバージョンは、review-deploy とreview-stop のジョブで使用されるregistry.gitlab.com/gitlab-org/gitlab-build-images:gitlab-helm3.5-kubectl1.17 イメージ で定義されています。

不健全なレビューアプリのリリースの診断

レビューアプリの安定性が低下した場合、review-apps クラスタが不健全であることを示すシグナルかもしれません。レビューアプリのデプロイにおいて、再起動につながるヘルスチェックの失敗や過半数の失敗が先行指標となる可能性があります。

レビューアプリの概要ダッシュボードは、クラスターの負荷スパイクを特定し、ノードに問題がある場合、またはクラスター全体が不健全な傾向にある場合に役立ちます。

レビューアプリリリースのトラブルシューティングについては、Engineering Productivity Runbookのレビューアプリのページを参照してください。

よくある質問

テスト実行のたびにCNGイメージのビルドをトリガーするのはやりすぎではありませんか？これは何千もの未使用のDockerイメージを作成します。

どこかで始めて、後で改善しなければなりません。また、これらのDockerイメージを保存するためにCNG-mirrorプロジェクトを使用しているので、ある時点でレジストリを消去して、新しく空のものを使用することができます。

悪用されないためのセキュリティは？アプリは世界中に公開されているので、私たちだけに限定する方法を見つける必要があります。

これはフォークには有効ではありません。

その他のリソース

便利なコマンドラインツール

  • K9s- ポッド間でCLIダッシュボードを使用可能にし、ラベルによるフィルタリングを可能にします。
  • Stern- ラベル/フィールドセレクタに基づいてポッド間のログテーリングを可能にします。

テストのドキュメントに戻る