Self-Managed Database Experience チーム

Self-Managed Database Experience チームは、Database Health チームの Self-Managed を担当していた部分と、別の Database Migrations チームが担当する予定だったアップグレードおよびマイグレーションの業務を統合し、2026 年 9 月に発足しました。

対象範囲

データベースの状態の可視化

私たちは、Self-Managed の管理者がデータベースの状態を把握できるようにし、安心してアップグレードし、アップグレードの間もデータベースの健全性を維持できるようにします。アップグレード前には、データベース、そのオブジェクト、設定の整合性をチェックします。アップグレードの間には、データベースのパフォーマンスと動作をチェックします。データベースの健全性と各問題の重大度を、管理者とサポートがプロダクト内の 1 か所で確認できるようにします。問題の検出は、私たちが責任を持って提供するものです。可能な場合は、見つかった問題を解決できるように管理者を案内するか、自動的に修正します。その結果、アップグレードの失敗、データベースのインシデント、データベース関連のサポートチケットが減少します。

マイグレーションのテスト

私たちは、すべてのマイグレーションが、お客様に届く前にデータを使ってテストされるようにします。複数バージョンにまたがるアップグレードテストでは、最新の必須経由バージョンのデータベースを復元し、それより新しいすべてのマイグレーションをそのデータベースに対して実行します。そのデータベースでデータが入っていないテーブルを変更するマイグレーションは、テストされないまま通過してしまいます。私たちはテーブルを所有する機能チームと協力し、すべてのテーブルにフィクスチャデータを用意し、フィクスチャデータがなければ新しいテーブルをマージできないようにします。その結果、お客様のアップグレード時に初めて失敗するマイグレーションが減少します。

アップグレード経路

私たちは、Self-Managed の管理者によるアップグレード計画を支援します。アップグレード経路を、アップグレードで実行するマイグレーションおよびその複雑さとともにプロダクト内に表示します。この情報は一般的な推定ではなく、インスタンス自体のデータに基づいているため、管理者はマイグレーションにかかり得る時間と、どのマイグレーションがパフォーマンスに影響し得るかを把握できます。そのうえで、管理者は安心してメンテナンス時間帯を計画できます。その結果、アップグレード中の予期せぬ遅延と、アップグレード関連のサポートチケットが減少します。

依存関係グラフによるマイグレーション

私たちはデータベースのマイグレーションを高速化し、Self-Managed のお客様のアップグレードにかかる時間を短縮します。マイグレーションは正しい順序で実行し、独立したマイグレーションは同時に実行します。マイグレーション作業の大半をメンテナンス時間帯より前に移し、ダウンタイムを短くします。お客様は中間バージョンを経由せず、目的のバージョンに直接アップグレードできます。各アップグレード後もデータが正しい状態に保たれることを保証します。

チーム

チームは、PostgreSQL と Rails のマイグレーションに関する豊富な経験を持つバックエンドエンジニアで構成されています。役割にかかわらず、すべてのチームメンバーは他の Database Excellence チームとともに、データベースレビュー、オンコールローテーション、運用上のニーズへの対応を含むステージレベルの責任を共有します。

Name	Role
Niko Belokolodov	Senior Backend Engineer, Database Health
Amandeep Singh	Intermediate Backend Engineer, Database
Imanpal Singh	Backend Engineer, Database
Krasimir Angelov	Staff Backend Engineer, Database

プロジェクト管理プロセス

私たちのチームは、Scrum を組み合わせた手法でプロジェクトを管理します。このプロセスは GitLab の月次マイルストーンのリリースサイクルに従います。

• 私たちは Issue ボードだけを基に作業します。Issue ボードが唯一の信頼できる情報源です。
• 私たちは Issue を次のワークフローステージへ継続的に移動します。
• 私たちはプロダクトとエンジニアリングの両方のイニシアチブに取り組みます。
• 私たちは取り組むすべての Issue に優先順位を付け、見積もります。
• 私たちは各月次マイルストーンの開始前に計画を立てます。
• 私たちは毎週チェックインを行い、チーム内で最新情報を共有します。

ワークフロー

プロダクト開発フローの以下のビルドステージラベルを使用します。

マイルストーンの計画とタイムライン

私たちはプロダクト開発のタイムラインに従います。私たちの成果を GitLab Self-Managed のリリースサイクルに沿ってリリースするためです。現在のマイルストーンの最後の 2 週間で、次のマイルストーンを計画します。次のマイルストーンが始まると、開発を開始します。

計画と分解のフェーズ

このフェーズは、現在のマイルストーンが終わる 2 週間前に始まります。

1. 初期計画
   1. PM: マイルストーン計画の Issue を作成し、マイルストーンの目標とテーマを追加します。
   2. PM: プロダクトの Issue を追加し、優先順位を付けます。
   3. EM: エンジニアリングの Issue と優先度の高いバグを追加し、優先順位を付けます。
   4. EM と PM: 計画 Issue に記載された Issue だけがマイルストーンに含まれていることを確認します。
2. 分解とウェイトの設定
   1. EM: 設定から 6 か月を超えたウェイトを削除し、ウェイトが未設定の Issue を ~"workflow::planning breakdown" に移動します。
   2. エンジニア: 解決策の提案がなければ追加し、自分の見積もりを追加し、質問し、ブロッカーへのリンクを追加し、必要に応じて Issue を分解します。
   3. EM: 見積もり済みの Issue を ~"workflow::ready for development" に移動します。
3. 最終計画
   1. EM: 現在のマイルストーンから持ち越される可能性の高い Issue を追加します。
   2. EM と PM: ウェイトに基づいて Issue を追加または削除します。
   3. EM: 次のマイルストーンボードで Issue に優先順位を付けます。
   4. EM と PM: 現在のマイルストーンの最後のチーム同期ミーティングで計画を提示します。

開発フェーズ

このフェーズは、新しいマイルストーンの初日に始まります。

• エンジニアは、関心と経験に基づき、現在のマイルストーンボードの Issue を優先順位に従って自分に割り当てます。
• Issue が残っていない場合、エンジニアはまず他のエンジニアが担当している Issue を手伝います。手伝うことがなければ EM に伝え、EM が次のマイルストーンから Issue を追加します。

マイルストーンのコミットメント

マイルストーンのコミットメントは、そのマイルストーンで完了することを目指す Issue の一覧です。私たちは野心的に計画を立てるため、必ずしもすべてを提供できるわけではありません。

期限

私たちは、提供予定時期をステークホルダーに伝えるために、Issue に期限を追加することがあります。期限はチームにプレッシャーをかけるものではありません。また、イテレーションに時間の上限を設けるためにも期限を使用します。たとえば、期限を 1 か月ではなく 1 週間にすると、より小さなイテレーションを見いだすのに役立ちます。

見積もり

私たちは Issue を非同期で見積もります。今後のマイルストーンに予定されている各 Issue に、初期ウェイトを設定します。

• 各 Issue には 2 件の見積もりが必要です。見積もりへの ➕ リアクションは同意として扱います。マイルストーン中に発生した Issue や、必要な知識を持つエンジニアが 1 人しかいない Issue は例外です。
• 2 件の見積もりが一致した場合、2 人目のエンジニアがウェイトを設定します。一致しない場合、2 人目のエンジニアが 1 人目のエンジニアをメンションして調整します。
• Issue に解決策の提案がない場合、または見積もりで別の解決策を提案する場合は、見積もりに解決策の提案を含めます。スパイクは例外で、デフォルトのウェイトは 8 です。
• 不明点が多い Issue は、高めに見積もります。

私たちは予測可能性よりも速度を重視します。見積もりは、MVCに集中し、見落としを見つけるのに役立ちます。予測可能性の目標は 90% ではなく 70% です。

ウェイト未設定の今後の Issueを参照してください。

見積もりの例

見積もりテンプレート

エンジニアは Issue に見積もりを追加する際、このテンプレートを使用できます。

### Refinement / Weighing

**Ready for Development**: Yes/No

<!--
Is the issue clear? Is it small enough, or can we break it into smaller issues? If so, how?
-->

**Weight**: X

**Reasoning**:

<!--
How can we break down this issue? Which code changes does it need? Link to prior art and similar examples.
-->

**Iteration MR/Issues Count**: Y

<!--
Can we split the issue into smaller issues or MRs? List them, and note any caveats.
-->

**Documentation required**: Yes/No

<!--
Do we need to add or change documentation?
-->

ページのソースコードを見る - ページの編集 - please contribute.