データベースマイグレーションパイプライン

GitLab 14.2で導入されました。

自動マイグレーションテストパイプラインにより、本番環境に近い環境でマイグレーションを自動的にテストすることができます（Database Labを使用）。これはアーキテクチャ・ブループリントに基づいています。

GitLab プロジェクトでは、新しいデータベースマイグレーションを追加する変更に対してマイグレーションテストが有効になります。このジョブを手動でトリガーするには、test ステージ内でdb:gitlabcom-database-testing ジョブを実行します。リソースの浪費を避けるため、このジョブは MR がレビュアーになる準備ができたときにのみ実行してください。さらに、パイプラインがテストステージに表示されるように、MR に “database” ラベルが付いていることを確認してください。

このジョブは、ops GitLabインスタンス上でパイプラインを開始します。セキュリティ上の理由から、パイプラインへのアクセスはデータベースメンテナーに制限されています。

パイプラインが開始されると、ボットがマージリクエストのコメントを通知します。終了すると、コメントはテスト結果で更新されます。

コメントには、main とci 両方のデータベースのテスト情報が含まれます。テストされた各データベースには、以下に説明する 4 つのセクションがあります。

要約

コメントの最初のセクションには、以下のようなテスト結果のサマリーが記載されています：

  • 警告- 例外や長時間実行されるクエリなどの重大なイシューを強調表示します。
  • マイグレーション- 各マイグレーションが完了するまでにかかった時間、成功したかどうか、データベース・サイズの増加。
  • ランタイム・ヒストグラム- このセクションを展開すると、すべてのマイグレーションにわたるクエリ実行時間のヒストグラムが表示されます。

マイグレーションの詳細

コメントの次のセクションには、各マイグレーションの詳細情報が記載されています：

  • 詳細- マイグレーションの種類、合計期間、データベースサイズの変更。
  • クエリ- マイグレーション中に実行されたすべてのクエリ、呼び出し回数、タイミング、変更された行の数。
  • ランタイム・ヒストグラム- マイグレーションにおけるクエリ時間のディストリビューションを示します。

データベースサイズの増加

マイグレーションによってサイズが増加すると予想されていないにもかかわらず、+8.00 KiB のサイズ増加が表示されることがあります。マイグレーションを完了すると、schema_migrations テーブルに行が追加され、新しいディスクページの作成が必要になる場合があります。新しいディスクページが作成されると、データベースのサイズはちょうど8 KiB増加します。

バックグラウンドマイグレーションの詳細

コメントの次のセクションには、以下のような各バッチバックグラウンドマイグレーションに関する詳細情報が記載されています：

  • サンプリング情報- このテスト実行中にサンプリングされたバッチ数。サンプリングされたバッチは、テーブルのID範囲にわたって均一に選択されます。サンプリングは30分間実行され、テストする各バックグラウンド・マイグレーションに均等に分割されます。
  • 集約クエリ情報- サンプリングされたすべてのバッチで実行された各クエリに関する集約データ、呼び出し回数、タイミング、変更された行数。
  • バッチ実行時間ヒストグラム- バックグラウンドマイグレーションからサンプルされた各バッチの時間のヒストグラム。
  • クエリ・ランタイム・ヒストグラム- このバックグラウンド・マイグレーションの任意のバッチで実行されたすべてのクエリのタイミングのヒストグラム。

クローンの詳細とアーティファクト

コメントの下に追加情報があります：

  • Migrations pending on GitLab.com - GitLab.comにまだデプロイされていないマイグレーションの概要。この情報は、マージされたもののまだデプロイされていないマイグレーションをテストするときに便利です。
  • Clone details- このテストパイプラインのために作成されたPostgres.ai シンクローンの有効期限に関する情報へのリンク。マイグレーションを実行した結果をさらに調べるために使用できます。データベースメンテナーまたはアクセスリクエストがある場合のみアクセスできます。
  • アーティファクト- パイプラインのアーティファクトへのリンク。各マイグレーション (.log で終わる) の完全なクエリログがあり、データベースメンテナーまたはアクセス要求がある場合のみアクセスできます。サンプリングされた特定のバッチバックグラウンドマイグレーションバッチの詳細もあります。

データベーステストパイプラインのテスト変更

データベーステストパイプライン自体の変更をテストするには、以下の手順が必要です：

  1. GitLab Orgに対するマージリクエスト。
  2. テストする変更が GitLab Ops 上のブランチに存在する必要があります。

GitLab Org上のマージリクエストをGitLab Ops上の任意のブランチに対してテストするには、この自己文書化されたスクリプトを使います：

#! /usr/bin/env bash

# The following must be set on a per-invocation basis:
TESTING_TRIGGER_TOKEN='[REDACTED]'              # Testing trigger token created in the CI section of the project
CI_COMMIT_REF_NAME='55-post-notice-on-failure'  # The branch on ops that you want to run against
CI_MERGE_REQUEST_IID='117901'                   # Merge request ID of the MR on gitlab.com that you want to test
SHA="fed6dd8a58d75a0e053a4972765b4fc08c5814a3"  # The commit SHA of the HEAD of the branch you want to test on gitlab-org/gitlab

# The following should not be changed between invocations:
CI_JOB_URL='https://gitlab.com/gitlab-org/database-team/gitlab-com-database-testing/-/jobs/1590162939'
# It doesn't appear that CI_JOB_URL has to be set to anything in particular for the pipeline to run
# successfully, but this would normally be the URL to the upstream job that invokes the DB testing pipeline.
CI_MERGE_REQUEST_PROJECT_ID='278964'    # gitlab-org/gitlab numeric ID. Shouldn't change.
CI_PROJECT_ID="gitlab-org/gitlab"       # The slug identifying gitlab-org/gitlab.

curl --verbose --request POST \
     --form "token=$TESTING_TRIGGER_TOKEN" \
     --form "ref=$CI_COMMIT_REF_NAME" \
     --form "variables[TOP_UPSTREAM_MERGE_REQUEST_IID]=$CI_MERGE_REQUEST_IID" \
     --form "variables[TOP_UPSTREAM_MERGE_REQUEST_PROJECT_ID]=$CI_MERGE_REQUEST_PROJECT_ID" \
     --form "variables[TOP_UPSTREAM_SOURCE_JOB]=$CI_JOB_URL" \
     --form "variables[TOP_UPSTREAM_SOURCE_PROJECT]=$CI_PROJECT_ID" \
     --form "variables[VALIDATION_PIPELINE]=true" \
     --form "variables[GITLAB_COMMIT_SHA]=$SHA" \
     --form "variables[TRIGGER_SOURCE]=$CI_JOB_URL" \
     "https://ops.gitlab.net/api/v4/projects/429/trigger/pipeline"