Content last updated 2026-09-22

Import グループ

Import グループはマイグレーションを支援します。

概要

Import グループは Create ステージの一部です。 このグループは、GitLab インスタンス間および他のプロバイダーからのマイグレーションを行うことで製品をサポートしています。

このページでは Import グループ固有のプロセスと情報をカバーします。グループの方向性ページおよびカテゴリーごとにサポートする機能も参照してください。

連絡方法

Import グループに連絡を取るには、GitLab プロジェクトで Issue を作成し、~"group::import" ラベルとその他の適切なラベルを付けるのがおすすめです。その後、 関連するプロダクトマネージャーやエンジニアリングマネージャーに気軽にメンションしてください。

より緊急性の高い案件については、Slack チャンネル（社内）#g_importを利用してください。

チームメンバー

以下の人々はこのグループの常任メンバーです。

NameRole
Carla DragoCarla DragoSenior Backend Engineer, Dedicated:Import
George KoltsovGeorge KoltsovSenior Backend Engineer, Dedicated:Import
James NuttJames NuttSenior Backend Engineer, Dedicated:Import
Oiza BaiyeOiza BaiyeFrontend Engineer, Dedicated:Import
Reza MarandiReza MarandiBackend Engineer, Dedicated:Import
Rodrigo TomonariRodrigo TomonariStaff Backend Engineer, Dedicated:Import
Sam WordSam WordSenior Backend Engineer, Dedicated:Import
Thiago FigueiróThiago FigueiróManager, Software Engineering, Dedicated:Import, Dedicated:Geo

作業

各マイルストーンの 1 週間前に、エンジニアリングマネージャーがチームの優先事項をまとめた 計画 Issue を作成します。チームメンバーは通知を受け、マイルストーンに対する自分のコミットメントで Issue を更新していきます。

Issue 開発ワークフロー

標準の GitLab エンジニアリングワークフローを使用しています。

Issue ボード

Import グループの作業は、以下の場所で追跡できます。

Issue ラベル

発見しやすくするため、Issue に正しいラベルを付けてください。

すべての Issue には以下が必要です。

  • ~"group::import"（ボットがステージとセクションのラベルを適切に付与します）
  • 1 つ以上のカテゴリーラベル:
    • ~"Category:Importers"（FIXME: 現在、ボットがすべての Issue にこのカテゴリーを強制的に付与しています）
    • ~"Category:Webhooks"
  • タイプラベル
  • ワークフローラベル
  • 該当する場合は ~"backend" または ~"frontend"

インポーターに関連する Issue には、Importer: ラベルも付けてください。例: ~"Importer:GitHub" または ~"Importer:Direct Transfer"。

バックログのリファインメント

エンジニアは通常、自分が取り組む予定の Issue をリファインメントします。ただし、特にコミュニティコントリビューターが 取り組む可能性がある場合は、誰でも Issue をリファインメントして開発の準備を整えることができます。

Issue がエピックの一部である場合、DRI がそれをリファインメントするか、そのエピックに アサインされたエンジニアにリファインメントを委任できます。誰がリファインメントを行うかにかかわらず、 マイルストーンが始まる前にリファインメントを完了することを目指してください。

遅くとも、エンジニアリングマネージャーが次のマイルストーンの計画 Issue を共有する時点 （現在のマイルストーン終了の 1 週間前に行われます）でリファインメントを開始すべきです。

リファインメント対象 Issue の特定

エンジニアリングマネージャーが Issue をスケジュールし、それらがマイルストーン計画 Issue に含まれます。

マイルストーンにおける各エンジニアの割り当てに基づき、Ready for Development ステータスでない Issue を特定します。 これらは通常 Refinement または Planning breakdown ステータスですが、任意の プロダクト開発フロー ステータスを取り得ます。

Ready for Development だが何か月も前にリファインメントされた Issue は、コードベース、製品、または アーキテクチャの方向性の変更に焦点を当てて、再度リファインメントすべきです。

Issue のリファインメント

Create ステージのクロスチーム計画とリファインメントのガイドライン、特にリファインメントおよび実装計画のセクションに従ってください。

Import グループでは、Issue がそれらのガイドラインに加え、以下の Import 固有の要件を満たした場合にリファインメント済みとみなされます。

  • 重み付け（type::bugs の場合は任意）
  • 別のエンジニアによるピアレビュー（重み 1 の Issue の場合は任意）。レビュー済みであることを示すため、レビュアーはコメントを残すか、Issue を Ready for development に移動できます
  • Ready for development ステータス

バグの準備状態

バグは、取り組む前に完璧に理解されている必要はないため、重みも不要です。

バグを完全に理解する労力は、しばしばそれを修正する労力の大半を占めます。したがって、 バグ Issue で提案された解決策は、欠陥に対する不完全な理解に基づいて行われた 提案とみなされる場合があります。

少なくとも以下を含めるようにしてください。

  • 再現手順
  • 現在の挙動
  • 期待される正しい挙動

バグテンプレート にはこれらのフィールドが含まれています。

ヘルプの依頼

サポート組織の一員でない場合は、まずサポートチームに連絡することをおすすめします。彼らはより多くの空き時間があり、一般的なほとんどの問題に対応できるためです。参加してフォローし、質問できる専用の Slack チャンネル #spt_pod_import があります。ただし、顧客の問題を解決するために深い技術的知識が必要となり、チームのエンジニアの関与が必要になる場合もあります。

エンジニアリングチームにヘルプを依頼する前に、まず関心のあるトピックについて GitLab ドキュメントと以下に挙げる追加リソースを確認してください。

上記のリソースで質問の答えが見つからない場合は、ヘルプ依頼（RFH）Issueを作成し、SupportRequestTemplate-Import テンプレートを使用してください。チームに連絡する前に、必要な情報をすべて提供してください。そうでない場合、私たちはあなたの依頼を進めることができません。新しい Issue は、社内のトリアージプロセスに従って優先順位付けされます。私たちは、現在のバージョンおよび直近の 2 つのマイナー GitLab バージョン（N-2）に影響する Issue の依頼のみをサポートできることにご注意ください。それより古いバージョンの修正は提供できません。これはバックポートのメンテナンスポリシーに沿ったものです。

マイルストーンドクター

各マイルストーンで、チームの 2 名のバックエンドエンジニアにマイルストーンドクターの役割が割り当てられ、1 名はプライマリ、もう 1 名はセカンダリとなります。割り当てはマイルストーンドクターのローテーションスケジュールにあります。エンジニアは今後のシフトを自由に交換し、スケジュールを更新できます。

セカンダリドクターは、プライマリが OOO またはキャパシティを超えている場合に、同じ責任を引き受けて代行します。それ以外の場合は、マイルストーンで計画されたタスクに取り組みます。プライマリドクターは、OOO になるときやキャパシティの問題に直面しているときにセカンダリに知らせるべきです。

プライマリドクターのマイルストーンキャパシティは 100% この役割の責任に割り当てられます。何も残っていない場合、エンジニアは ~type::maintenance または ~type::bug Issue に取り組み、コードレビューのキャパシティを増やすことを検討すべきです。

現在のドクターは @gitlab-com/create-team/import/reaction-rotation でタグ付けできます。

責任

  • 新しい RFH Issueについてサポートおよび PS と連携する
  • 長期間オープンな Issue をフォローアップする
  • 顧客との通話でサポートチームを支援する
  • マイルストーンドクターが問題を診断することに成功した方法に関するチームランブックのドキュメントを維持する
  • チームの Slack チャンネル #g_import での質問に対応する
  • シフトから学んだことで FAQ を更新する
  • インポーターの依存関係をレビューし、サードパーティ API の変更による 必要な変更のための Issue を作成する
  • エラーがないか #import_exceptions と Direct Transfer Kibana Dashboard を監視し、必要に応じてトリアージ、エスカレーション、フォローアップ Issue の作成を行う
  • マイルストーンごとに 1 回、エラーバジェットをレビューし、リグレッションを調査して、見つかった問題についてフォローアップ Issue を作成する
  • マイルストーンの終わりに @gitlab-com/create-team/import/reaction-rotation のメンバーシップを更新する
インポーターの依存関係

マイルストーンごとに 1 回、各インポーターの依存関係の変更履歴をレビューし、今後の破壊的変更や API の非推奨化を確認します。GitLab Duo Chat を使用して 影響を評価し、更新が必要な変更については関連する ~"Importer:" ラベルを付けた Issue を作成します。

レビュー後、計画 Issue にサマリーと作成した Issue へのリンクを含むコメントを残します。 注目してもらうために EM をタグ付けします。

推奨プロンプト

[START_DATE] を、依存関係を最後に確認した日付に置き換えてください。

You are helping an engineer on the GitLab Import team perform a periodic review of third-party API dependencies. Our importers integrate with external services and we need to check their changelogs for any breaking changes, deprecations, or required migrations announced since [START_DATE].

Review the following changelog pages and identify any changes that could break or require updates to our importers:

**GitHub importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/github_import
- Changelogs: https://docs.github.com/en/rest/about-the-rest-api/breaking-changes, https://github.blog/changelog/, https://github.com/octokit/octokit.rb/releases

**Bitbucket Cloud importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/bitbucket, https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/bitbucket_import
- Changelogs: https://developer.atlassian.com/cloud/bitbucket/changelog/

**Bitbucket Server importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/bitbucket_server, https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/bitbucket_server_import
- Changelogs: https://developer.atlassian.com/server/bitbucket/changelog/

**Gitea importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/import/gitea_controller.rb (uses GitHub import client)
- Changelogs: https://github.com/go-gitea/gitea/blob/main/CHANGELOG.md, https://blog.gitea.com

**Jira importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/jira_import
- Changelogs: https://developer.atlassian.com/cloud/jira/platform/changelog/, https://github.com/sumoheavy/jira-ruby/releases

**FogBugz importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/fogbugz_import
- Changelogs: https://support.fogbugz.com/section/3113-articles

For each change you find, check the corresponding GitLab implementation to verify whether the change affects us.

Then, for each importer, list:
1. The name of the importer
2. Whether changes are required
3. A summary of the required change (for changes that do not affect us, simply provide a link to
   the announcement)
4. The due date or enforcement date

If no actionable changes are found, confirm that and note the date range you checked.

セキュリティとの連携

このグループには、セキュリティに影響を及ぼす可能性のある Issue を特定するのに役立つ既存の脅威モデルがありますが、他にも考慮すべき点があります。

Issue や MR がセキュリティに影響を及ぼす可能性がある場合、アプリケーションセキュリティレビューを依頼すべきです。これには以下が含まれますが、これらに限りません。次のような Issue や MR です。

  • 脅威モデルに該当するもの
  • バイナリファイルを扱うもの（ダウンロード、展開、抽出、移動、削除）
  • ファイル操作サービスを変更または使用するもの
  • Import/Export の CommandLineUtil のメソッドを使用するもの

長期間存続するフィーチャーフラグ

これは、フィーチャーフラグの使用に関する GitLab の一般的な開発ガイダンスの補足です。ops タイプを除くすべてのフラグタイプに適用されます。

Import 機能の変更は、しばしばトラフィックの多いコードパスで発生し、過去に GitLab.com の障害を 引き起こしてきました。障害はしばしばリソースの競合に関係しており、コードレビューや QA テストで事前に 把握するのが難しい場合があります。

  • 大規模なインポートは数千のワーカーをトリガーすることがあります。
  • インテグレーションと Webhook は 1 日に数百万回実行されます。
  • 競合の問題は、すぐには表面化せず、大規模な顧客が新しいコードパスをトリガーしたときにのみ現れることがあります。

このため、フィーチャーフラグを通常よりも長い期間コードベースに残すことを優先すべきです。 この期間中、フラグはデフォルトで有効ですが、インシデントの際にすばやく無効化できます。

過去には、機能を無効化することで複数のインシデントを迅速に緩和できました。

インポーター、インテグレーション、または Webhook 内の変更については、以下を優先すべきです。

  1. 通常どおり /chatops でフラグをロールアウトする。
  2. スケールでの問題を事前に洗い出すため、大規模なデータを使用して変更を QA する。 インポーターについては、ヒントについて私たちのランブック を参照してください。
  3. 機能をリリースする段階になったら、フィーチャーフラグを削除するのではなく default_enabled: true に変更します。これはフラグロールアウト Issue における 任意のフラグ付きでの機能リリース のステップです。
  4. この時点で、機能はマイルストーン内でリリースされたとみなされ、Self-Managed 顧客に出荷されるため、リリースポストで 発表できます。
  5. フラグがコードベースに存在しつつデフォルトで有効なままの状態を 1〜3 週間待ちます。 競合がより多い領域での変更や、何らかの理由で問題の検出に時間がかかると感じる場合は、より長い期間を 使用してください。
  6. その期間の後、フィーチャーフラグを削除してフラグロールアウトプロセスを完了します。

リリース中

  • Kickoff 後に Issue がリリースに導入される場合、計画外の作業を考慮するために同じ量の重みを取り除く必要があります。
  • Issue は見積もりが行われ、重みが付けられる前に開発を開始すべきではありません。
  • 15 日までに、エンジニアリングのマージリクエストはマージされているべきです。言い換えれば、15 日以降にマージされたコードはリリースに含まれないと想定します。これにより、リリースを最終化し、関連するリリースポストを 17 日までにマージする時間が確保されます。（これは 13.11 から開始された実験です。）

リリースポスト

より詳細に発表する必要がある Issue については、その Issue を使用してリリースポストを自動的に作成できます。 Issue に取り組む際、計画段階でも、設計・開発中でも、 リリースノートライターエージェント を使用して、リリースポストを作成し、関連するすべての人に通知できます。

Issue にリリースポストを持たせたくない場合は、その Issue に リリースノートのセクションがないこと、または release post item:: ラベルを使用しないことを確認してください。

概念実証 MR

私たちはイテレーションと小さな増分で価値を届けることを強く信じています。イテレーションは難しいことがあり、特に製品コンテキストが不足している場合や、コードベースの特にリスクが高い／複雑な部分で作業している場合はそうです。Issue の見積もりや実現可能性の判断に苦労している場合、まず概念実証（PoC）MR を作成するのが適切かもしれません。概念実証 MR の目的は、計画中の大きな前提を取り除き、早期のフィードバックを提供することで、将来の実装のリスクを軽減することです。

  • PoC: を接頭辞に付けた MR を作成します。
  • PoC MR が解決しようとしている問題を MR の説明で説明します。
  • タイムボックスを設けます。2〜3 日未満で実現可能性や計画を判断できますか？
  • この期間の終わりにフィードバックを提供するレビュアーを特定します。
  • MR をクローズします。製品およびパフォーマンスへの影響を含め、PoC から学んだことを元の Issue にサマリーとして提供します。
    • 実装に進めるかどうかを述べます。
    • Issue はクローズしないでください。

概念実証 MR の必要性は、私たちのコードベースや製品の一部が過度に複雑になっていることを示唆している可能性があります。将来このステップを回避する方法を議論できるよう、レトロスペクティブの一環として MR について議論する価値が常にあります。

レトロスペクティブ

定期的にスケジュールされた「マイルストーンごと」のレトロスペクティブが 1 回あり、アドホックな「プロジェクトごと」のレトロスペクティブを行うこともできます。

マイルストーンごと

Import グループは GitLab Issue でマイルストーンレトロスペクティブを実施しています。これには、エンジニア、UX、PM、および マイルストーン中にそのチームと協働したすべての安定したカウンターパートが含まれます。

すべてのマイルストーンで私たちのチームメンバーの参加が強く推奨されます。

これらは最初の議論中は機密扱いとされ、その後、毎月の GitLab レトロスペクティブに間に合うように公開されます。詳細については、グループレトロスペクティブを参照してください。

プロジェクトごと

特定の Issue、機能、またはその他の種類のプロジェクトが 特に有用な学びの経験になった場合、それから学ぶために同期または 非同期のレトロスペクティブを行うことがあります。取り組んでいる何かが レトロスペクティブに値すると感じた場合は、

  1. レトロスペクティブを行いたい理由を説明するIssue を作成し、これが同期か非同期かを示します。
  2. EM および関与すべきその他の人（PM、カウンターパートなど）を含めます。
  3. 該当する場合は同期ミーティングを調整します。

レトロスペクティブからのすべてのフィードバックは、参照目的で最終的に Issue に集約されるべきです。

テックリード

私たちのグループは、さまざまなトピックに関する作業を整理し、それらの DRI を特定するのを助けるためにテックリードと協働しています。

テックリードの特徴

テックリードとは、

  • 追加の責任を持つ個人コントリビューターです。シニアリティに関わらず、すべてのエンジニアがテックリードになる資格があります。
  • 特定のトピック／プロジェクトに紐づく一時的な役割です。異なるトピック／プロジェクトのために、チームが同時に複数のテックリードを持つことを許可しています。
  • マネージャーではありません。
  • 追加のシニアリティレベルではありません。

テックリードの役割は、リーダーシップスキルの習得に関心のあるエンジニアに成長の機会を提供します。

テックリードの責任

テックリードは多くの役割を担います。その責任はプロジェクトごとに異なる場合がありますが、以下を含むことがあります。

  • 技術的ビジョンとアーキテクチャ - 特定のプロジェクトの全体的な技術アーキテクチャを定義し、進化させる
  • 技術的ガイダンス - チームの他の開発者に技術的ガイダンスとメンタリングを提供する
  • 作業の計画と優先順位付け - 大きなタスクを小さく実行可能なアイテムに分解して作業を整理する
  • 進捗の追跡 - コミットメントの進捗を追跡し、ステータス更新を報告する
  • リスク管理 - 成果物に影響を及ぼす可能性のある技術的リスクを特定、評価、管理する
  • 調整 - 他者の作業を監督し、ブロッカーの除去を支援する
  • 技術ドキュメント - 他の開発者のために技術アーキテクチャとコード構造のドキュメントを維持する

現在のテックリード

以下は、テックリードによって監督されているトピックの概要です。

トピックテックリードトピックリンク備考
Direct Transfer - ユーザーコントリビューションマッピングRodrigo Tomonariエピック-
インポーターへの開発者コントリビューションの効率を改善するJames NuttOKR-
Congregatetbdhttps://gitlab.com/gitlab-org/gitlab/-/issues/428657
GitHub Actionstbdhttps://gitlab.com/gitlab-org/manage/general-discussion/-/issues/17652

マージリクエストのルーレットレビュー

Import コードベースの領域が変更されると、レビュアールーレット が、そのマージリクエストを Import チームメンバーがレビューすることを推奨します。これは、Import チーム外の人々によって 作成されたマージリクエストの場合にのみ発生します。レビュー推奨がどのように見えるかはこの例を参照してください。

これらの特別な推奨の理由は、 他のグループが特定のインテグレーションや Webhook の一部の所有権を持っているためです。 チーム外のメンバーによる変更をレビューすることで、基盤コードの所有者として行動し、 Import コードベースのより良い品質を維持できます。

ルーレットマッチの仕組み

マージリクエスト内の変更のファイルパスは、 正規表現のリスト と照合されます。ルーレットはこれらのハッシュ値を使用してレビュアーグループを推奨します。例えば、:import_integrate_be と :import_and_integrate_fe はそれぞれ Import のバックエンドとフロントエンドのレビューを推奨します。正規表現のマッチは 最初のマッチが優先 であり累積的ではないため、:backend や :frontend などの他の関連するレビュアーグループも 各ハッシュ値に含める必要があります。

正規表現リストは、必要に応じてインテグレーションや Webhook のコードに一致するように更新すべきです。リストは私たちの 一般的に名前空間化されたファイルに一致するため、既存の名前空間内の新しいコードは常に一致します。

GitLab リポジトリ内のどのファイルがマッチを生成するかを確認するには、以下を Rails コンソールに貼り付けてください。

require Rails.root.join('tooling/danger/project_helper.rb')

ALL_FILES = Dir.glob('**/*');

def category_regexs(category)
  matching_categories = Tooling::Danger::ProjectHelper::CATEGORIES.select do |regexs, categories|
    next if regexs.is_a?(Array)

    Array.wrap(categories).include?(category)
  end

  regexes = matching_categories.map(&:first)
  Regexp.union(*regexes)
end

def print_files(category)
  regex = category_regexs(category)

  puts ALL_FILES.grep(regex).reject { |path| File.directory?(path) }.sort
end

puts "Backend:\n"
print_files(:import_integrate_be)

puts "Frontend:\n"
print_files(:import_integrate_fe)

モニタリング

これは、私たちの機能を監視するためのリンク集です。

Grafana ダッシュボード

Sentry エラー

Kibana ダッシュボード

すべての Import Kibana ダッシュボードのリストを参照してください。

インポーターダッシュボード:

API/Webhook ダッシュボード:

Kibana ログ

GitLab for Jira Cloud アプリのワーカー:

エラーバジェット

GitLab はエラーバジェットを使用して、私たちの機能の可用性とパフォーマンスを測定します。 各エンジニアリンググループには独自のバジェット消費があります。Import チームの現在の 28 日間の消費は、 この Grafana ダッシュボードに表示されます。

エラーバジェットの消費は、以下のいずれかが一定のしきい値を超えると発生します。

  • エンドポイントまたはワーカーのエラー率
  • エンドポイントの Apdex（レイテンシー）

最も影響の大きい修正を特定する

Grafana ダッシュボードで最も優先度の高い問題を特定するには、

  1. Error budget パネルに移動します。
  2. Budget spend attribution を展開します。Budget failures パネルは、上位の失敗順に並べられています。
  3. Failure log links で、対応するリンクをクリックします。

上位の原因を修正することで、バジェット消費に最大の影響を与えられます。

さらなるリソース

これらのリソースでエラーバジェットについてさらに学べます。

使用状況データダッシュボード

機能の使用状況データは Tableau で確認できます。

最終更新 October 28, 2026: Merge pull request #591 from kyama0/translation/batch-2026-10-28-1 (5d840611)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License