マイグレーション

(トップページはこちら) - (プロジェクトで作業を整理する)

GitLabへのプロジェクト移行は、単なるコードの引っ越しではありません。チームの開発履歴、コントリビューション、メンバーシップといった重要な資産を、いかに正確かつ効率的に移行できるかが鍵となります。本記事では、GitLab.comが提供する移行機能とプロジェクト管理の実践的なアプローチを解説します。

1. 多様な移行元に対応する柔軟性

GitLabは、さまざまなプラットフォームからの移行をサポートしています。以下の表は、各プラットフォームに対する移行ツールの対応状況を示しています。

移行元プラットフォーム	GitLab移行ツール対応
Bitbucket Cloud	✓ 対応
Bitbucket Server	✓ 対応
GitHub	✓ 対応
Gitea	✓ 対応
GitLab間の直接転送	✓ 対応
GitLabファイルエクスポート	✓ 対応
Jira (イシューのみ)	✓ 対応
FogBugz	✓ 対応
Gitリポジトリ (URL経由)	✓ 対応
Gitリポジトリ (マニフェスト経由)	✓ 対応
ClearCase	× 未対応
CVS	× 未対応
Perforce Helix	× 未対応
TFVC	× 未対応

未対応のシステムからの移行については、git svnやreposurgeonなどのサードパーティツールを活用することで対応可能です。

重要な注意事項:

移行を開始した後は、移行元インスタンスのインポート対象グループやプロジェクトに変更を加えないでください。これらの変更は移行先インスタンスにコピーされない可能性があります。

2. プレースホルダーユーザーによる段階的な移行

GitLab 17.4以降で導入された「ユーザーコントリビューションとメンバーシップマッピング」機能は、移行プロセスに革新をもたらしました。この機能の核心は、プレースホルダーユーザーという概念です。

2.1 プレースホルダーユーザーの仕組み

移行時、すべてのコントリビューションとメンバーシップは、まずプレースホルダーユーザーに割り当てられます。これにより、移行元と移行先でメールアドレスが異なるユーザーでも、正確にマッピングできるようになります。

プレースホルダーユーザーには以下の特徴があります。

制限事項:

• ログイン不可
• アクション実行不可(パイプライン実行など)
• アサイニーやレビュアーの候補に表示されない
• プロジェクトやグループのメンバーとして表示されない

保持される情報:

• ソースユーザーID (source_user_id)
• ソースホスト名 (source_hostname)
• ソース名 (source_name)
• ソースユーザー名 (source_username)
• インポートタイプ (import_type)
• 作成タイムスタンプ (created_at)

プレースホルダーユーザーの命名規則は、元のユーザー情報を保持します。

• 名前: Placeholder <元のユーザー名>
• ユーザー名: <元のユーザー名>_placeholder_user_<連番>

例外ケース:

以下の場合、プレースホルダーユーザーは作成されません。

• Giteaからプロジェクトをインポートし、ユーザーがインポート前にGiteaで削除されていた場合(コントリビューションはインポートを実行したユーザーにマッピング)
• プレースホルダーユーザー上限を超えた場合(コントリビューションはImport Userにマッピング)
• 個人名前空間にインポートする場合(コントリビューションは個人名前空間の所有者に割り当て)

2.2 プレースホルダーユーザーの上限管理

GitLab.comでは、プランと座席数に応じてプレースホルダーユーザーの上限が設定されています。プレースホルダーユーザーはライセンス制限にカウントされません。

プラン	座席数	プレースホルダー上限
Free / トライアル	任意	200
Premium	100未満	500
Premium	101-500	2,000
Premium	501-1,000	4,000
Premium	1,000超	6,000
Ultimate / OSS	100未満	1,000
Ultimate / OSS	101-500	4,000
Ultimate / OSS	501-1,000	6,000
Ultimate / OSS	1,000超	8,000

現在の使用状況と上限の確認方法:

1. サイドバーで検索または移動からグループを検索(トップレベルグループである必要があります)
2. 設定 > 使用量クォータを選択
3. インポートタブを選択

上限に達した場合、すべてのコントリビューションはImport Userという単一の非機能ユーザーに割り当てられます。この状態では、重複排除が発生し、以下のコントリビューションが失われる可能性があります。

• 承認ルール
• 絵文字リアクション
• イシューアサイニー
• メンバーシップ
• マージリクエストの承認、アサイニー、レビュアー
• プッシュ、マージリクエスト、デプロイのアクセスレベル

事前にプレースホルダーユーザー数を決定することはできないため、余裕を持った計画が重要です。

2.3 プレースホルダーユーザーの確認方法

プレースホルダーユーザーを確認するには、以下の手順を実行します。

1. サイドバーで検索または移動からグループを検索(トップレベルグループである必要があります)
2. 管理 > メンバーを選択
3. プレースホルダータブを選択

2.4 プレースホルダーユーザーの作成ルール

プレースホルダーユーザーは、インポートソースとトップレベルグループごとに作成されます。

• 同じプロジェクトを同じトップレベルグループに2回インポートした場合、2回目のインポートは1回目と同じプレースホルダーユーザーを使用します
• 同じプロジェクトを異なるトップレベルグループにインポートした場合、2回目のインポートは新しいプレースホルダーユーザーを作成します

ユーザーが再割り当てを承認すると、同じソースインスタンスから同じトップレベルグループまたはサブグループへの今後のインポートでは、プレースホルダーユーザーは作成されず、コントリビューションは自動的にそのユーザーにマッピングされます。

2.5 プレースホルダーユーザーの削除

プレースホルダーユーザーを含むトップレベルグループを削除すると、これらのユーザーは自動的に削除予定としてスケジュールされます。このプロセスには時間がかかる場合があります。ただし、他のプロジェクトやグループにも関連付けられている場合、プレースホルダーユーザーはシステムに残ります。

3. コントリビューションの再割り当て戦略

移行後、プレースホルダーユーザーのコントリビューションを実際のユーザーに再割り当てする方法は2つあります。

3.1 再割り当ての前提条件

• 有料の名前空間を設定済みである必要があります
• GitLab.comでSAML SSOを使用している場合、すべてのユーザーがSAMLアイデンティティをGitLab.comアカウントにリンクしている必要があります

3.2 UI経由での個別割り当て

少数のプレースホルダーユーザーを扱う場合に適しています。

1. グループの管理 > メンバーに移動
2. プレースホルダータブを選択
3. 再割り当て待ちサブタブで各プレースホルダーを確認
4. プレースホルダーユーザー列とソース列で情報を確認
5. プレースホルダーを再割り当て列でドロップダウンリストからユーザーを選択
6. 再割り当てをクリック

1つのプレースホルダーユーザーのコントリビューションは、1人のアクティブな非ボットユーザーにのみ再割り当てできます。

3.3 CSV一括割り当て

大量のプレースホルダーユーザーを効率的に処理する場合に最適です。

1. グループの管理 > メンバー > プレースホルダータブに移動
2. CSVで再割り当てを選択
3. 事前入力されたCSVテンプレートをダウンロード
4. GitLabユーザー名またはGitLab公開メール列に宛先ユーザー情報を入力
5. 完成したCSVファイルをアップロード
6. 再割り当てを実行

CSVテンプレートの構造:

ソースホスト	インポートタイプ	ソースユーザー識別子	ソース名	ソースユーザー名	GitLabユーザー名	GitLab公開メール
gitlab.example.com	gitlab	tanaka	田中太郎	t.tanaka	tanaka_taro	[e-mail]

重要な注意事項:

• ソースホスト、インポートタイプ、ソースユーザー識別子は更新しないでください。これらの情報は、アップロード後に対応するデータベースレコードを特定するために使用されます
• ソース名とソースユーザー名はソースユーザーの識別用で、アップロード後は使用されません
• CSVファイルのすべての行を更新する必要はありません。GitLabユーザー名またはGitLab公開メールが入力されている行のみが処理され、その他の行はスキップされます

再割り当て後、GitLabは以下の情報を含むメールを送信します。

• 正常に処理された行数
• 処理に失敗した行数
• スキップされた行数

処理に失敗した行がある場合、メールには詳細な結果を含むCSVファイルが添付されます。

3.4 複数のプレースホルダーユーザーからの再割り当て

1つのプレースホルダーユーザーに割り当てられたすべてのコントリビューションを、1人のアクティブな通常ユーザー、サービスアカウント、プロジェクトボット、グループボットに再割り当てできます。1つのプレースホルダーユーザーのコントリビューションを複数のユーザーに分割することはできません。

以下の場合、複数のプレースホルダーユーザーのコントリビューションを同じユーザーに再割り当てできます。

• 異なるソースインスタンスからのプレースホルダーユーザー
• 同じソースインスタンスからのプレースホルダーユーザーで、移行先インスタンスの異なるトップレベルグループにインポートされた場合

割り当てられたユーザーが再割り当てリクエストを承認する前に非アクティブになった場合、保留中の再割り当てはユーザーが承認するまでそのユーザーにリンクされたままになります。

サービスアカウント、プロジェクトボット、グループボットに再割り当てする場合、再割り当てリクエストは自動的に承認されます。

3.5 再割り当ての承認プロセス

通常、ユーザーは再割り当てリクエストをメールで受け取り、承認または拒否できます。

承認時の動作:

• すべてのコントリビューションとメンバーシップが実ユーザーに再割り当てされます(処理には数分かかる場合があります)
• 同じソースインスタンスから同じトップレベルグループへの今後のインポートで、コントリビューションは自動的にそのユーザーにマッピングされます

拒否時の動作:

• 再割り当てリクエストメールで拒否またはスパムとして報告できます

セキュリティ考慮事項:

再割り当てリクエストを受け取ったユーザーは、以下の詳細を慎重に確認する必要があります。

• インポート元: インポートされたコンテンツの元のプラットフォーム(別のGitLabインスタンス、GitHub、Bitbucketなど)
• 元のユーザー: ソースプラットフォームでのユーザー名とユーザー名(そのプラットフォームでの自分の名前とユーザー名である可能性があります)
• インポート先: 新しいプラットフォームの名前(GitLabインスタンスのみ)
• 再割り当て先: GitLabインスタンスでのフルネームとユーザー名
• 再割り当て実行者: インポートを実行した同僚またはマネージャーのフルネームとユーザー名

再割り当ては取り消し不可であり、誤った再割り当ては不適切なアクセス権限付与につながる可能性があります。疑わしい点がある場合は、承認せずに信頼できる同僚またはマネージャーに相談してください。

再割り当てプロセスは、GitLabで再割り当てを承認を選択した後にのみ開始されます。メール内のリンクを選択しても開始されません。

3.6 エンタープライズユーザーの確認バイパス

GitLab 18.4以降、GitLab.comのPremiumおよびUltimateプランでは、エンタープライズユーザーへの再割り当て時に確認をバイパスできます。

1. サイドバーで検索または移動からグループを検索(トップレベルグループである必要があります)
2. 設定 > 一般を選択
3. 権限とグループ機能を展開
4. プレースホルダーユーザー確認で、ユーザー確認なしでエンタープライズユーザーにプレースホルダーを再割り当てチェックボックスを選択
5. ユーザー確認を復元するタイミングで、ユーザー確認のバイパスを終了する日付を選択(デフォルト値は1日)
6. 変更を保存を選択

この機能は、組織外のユーザーへの誤った再割り当てを防ぐことを目的としています。

3.7 プレースホルダーとして保持する選択肢

元従業員など、移行先インスタンスにユーザーが存在しない場合、プレースホルダーユーザーとしてコントリビューションを保持できます。プレースホルダーユーザーはプロジェクトやグループのメンバーになれないため、メンバーシップ情報は保持されません。

プレースホルダーユーザーの名前とユーザー名はソースユーザーの名前とユーザー名に似ているため、多くの履歴コンテキストを保持できます。

個別保持:

1. プレースホルダータブの再割り当て待ちサブタブで対象を選択
2. プレースホルダーユーザー列とソース列で保持するプレースホルダーユーザーを確認
3. プレースホルダーを再割り当て列で再割り当てしないを選択
4. 確認をクリック

一括保持:

一括で保持する場合、名前空間全体と以下の再割り当てステータスを持つユーザーが影響を受けます。

• 未開始
• 拒否済み

手順:

1. プレースホルダータブで縦の省略記号(⋮)をクリック
2. すべてをプレースホルダーとして保持を選択
3. 確認ダイアログで確認をクリック

操作の取り消し(GitLab 18.5以降):

1. プレースホルダータブの再割り当て済みサブタブに移動
2. 該当する行で元に戻すを選択

3.8 再割り当てリクエストのキャンセル

ユーザーが再割り当てリクエストを承認する前に、リクエストをキャンセルできます。

1. プレースホルダータブの再割り当て待ちサブタブに移動
2. 該当する行でキャンセルを選択

3.9 保留中の再割り当てリクエストの再通知

ユーザーが再割り当てリクエストに対応していない場合、別のメールを送信して再度促すことができます。

1. プレースホルダータブの再割り当て待ちサブタブに移動
2. 該当する行で通知を選択

3.10 再割り当てステータスの確認

プレースホルダーユーザーの再割り当てステータスは、プレースホルダータブの再割り当てステータス列で確認できます。

再割り当て待ちタブでのステータス:

• 未開始 - 再割り当てが開始されていない
• 承認待ち - ユーザーの承認待ち
• 再割り当て中 - 再割り当て処理中
• 拒否済み - ユーザーが拒否
• 失敗 - 再割り当て失敗

再割り当て済みタブでのステータス:

• 成功 - 再割り当て成功
• プレースホルダーとして保持 - プレースホルダーユーザーとして永続化

デフォルトでは、テーブルはプレースホルダーユーザー名のアルファベット順にソートされます。再割り当てステータスでソートすることも可能です。

3.11 再割り当て完了の重要性

以下の操作を行う前に、再割り当てプロセスを完全に完了する必要があります。

• インポートされたグループを同じGitLabインスタンス内で移動
• インポートされたプロジェクトを別のグループに移動
• インポートされたイシューを複製
• インポートされたイシューをエピックに昇格

プロセスが完了していない場合、プレースホルダーユーザーに割り当てられたままのコントリビューションは実ユーザーに再割り当てできず、プレースホルダーユーザーに関連付けられたままになります。

3.12 メンバーシップのセキュリティ考慮事項

GitLabの権限モデルにより、グループまたはプロジェクトが既存の親グループにインポートされると、親グループのメンバーはインポートされたグループまたはプロジェクトの継承メンバーシップを付与されます。

インポートされたグループまたはプロジェクトの既存の継承メンバーシップを持つユーザーをコントリビューションとメンバーシップの再割り当てに選択すると、メンバーシップの再割り当て方法に影響を与える可能性があります。

GitLabでは、子プロジェクトまたはグループのメンバーシップが継承メンバーシップよりも低いロールを持つことを許可していません。割り当てられたユーザーのインポートされたメンバーシップが既存の継承メンバーシップよりも低いロールを持つ場合、インポートされたメンバーシップはそのユーザーに再割り当てされません。

これにより、インポートされたグループまたはプロジェクトに対するメンバーシップが、ソースでのメンバーシップよりも高くなります。

4. プロジェクト管理の実践的機能

4.1 プロジェクト概要

プロジェクトを選択すると、プロジェクト概要ページにプロジェクトの内容が表示されます。

表示される情報:

• リポジトリ内のファイル
• プロジェクト情報(説明)
• トピック
• バッジ
• プロジェクト内のスター、フォーク、コミット、ブランチ、タグ、リリース、環境の数
• プロジェクトストレージサイズ
• オプションのファイルと設定(README、Wiki、ライセンス、変更履歴、コントリビューションガイドライン、Kubernetesクラスター、CI/CD設定、統合、GitLab Pages)
• 作成日

4.2 プロジェクトの可視性とアクセス制御

プロジェクトIDを使用したアクセスが可能です。

• 通常のパス: https://gitlab.com/yamada/my-project
• IDベースのパス: https://gitlab.com/projects/123456
• 短縮パス(GitLab 17.5以降): https://gitlab.com/-/p/123456

例えば、個人名前空間yamadaにmy-projectというプロジェクト(ID 123456)がある場合、https://gitlab.com/yamada/my-projectまたはhttps://gitlab.com/projects/123456のいずれかでアクセスできます。

4.3 プロジェクトIDの確認方法

プロジェクトIDは、GitLab APIとの連携などで必要になります。

1. サイドバーで検索または移動からプロジェクトを検索
2. プロジェクト概要ページの右上でアクション(⋮)を選択
3. プロジェクトIDをコピーを選択

4.4 プロジェクトの表示とフィルタリング

GitLab.comでは、さまざまな方法でプロジェクトを表示・フィルタリングできます。

プロジェクト一覧の表示:

1. サイドバーで検索または移動を選択
2. すべてのプロジェクトを表示を選択
3. タブを選択してフィルタリング:
   • コントリビュート済み: イシュー、マージリクエスト、エピックの作成・コメント・クローズ、コミットのプッシュ、マージリクエストの承認・マージを行ったプロジェクト
   • スター付き: スターを付けたプロジェクト
   • 個人: 個人名前空間で作成したプロジェクト
   • メンバー: メンバーとして参加しているプロジェクト
   • 非アクティブ: アーカイブ済みおよび削除保留中のプロジェクト

プログラミング言語でフィルタリング:

1. 検索または移動 > すべてのプロジェクトを表示を選択
2. プロジェクト一覧の上部で検索またはフィルター結果を選択
3. 言語ドロップダウンリストから言語を選択

所有者でフィルタリング:

1. 検索または移動 > すべてのプロジェクトを表示を選択
2. プロジェクト一覧の上部で検索またはフィルター結果を選択
3. ロールドロップダウンリストから所有者を選択

4.5 非アクティブなプロジェクトの表示

プロジェクトは、削除保留中またはアーカイブ済みの場合に非アクティブになります。

1. すべてのプロジェクトを表示または探索を選択
2. 非アクティブタブを選択

各非アクティブなプロジェクトには、プロジェクトがアーカイブ済みまたは削除保留中であることを示すバッジが表示されます。

プロジェクトが削除保留中の場合、リストには以下も表示されます。

• プロジェクトが最終削除される予定時刻
• 復元アクション。プロジェクトを復元すると、削除保留中ラベルが削除され、プロジェクトは削除予定から外れ、非アクティブタブから削除されます

4.6 プロジェクトのスター機能

頻繁に使用するプロジェクトにスターを付けることで、見つけやすくなります。

1. サイドバーで検索または移動からプロジェクトを検索
2. ページ右上のスターを選択

4.7 プロジェクトからの離脱

プロジェクトから離脱すると、以下の変更が発生します。

• プロジェクトメンバーではなくなり、コントリビュートできなくなります
• 自分に割り当てられていたすべてのイシューとマージリクエストが未割り当てになります

前提条件:

• プロジェクトがグループ名前空間下のグループの一部である必要があります
• プロジェクトの直接メンバーである必要があります

手順:

1. サイドバーで検索または移動からプロジェクトを検索
2. プロジェクト概要ページの右上でアクション(⋮)を選択
3. プロジェクトから離脱を選択し、再度プロジェクトから離脱を選択

4.8 プロジェクトアクティビティの追跡

プロジェクトアクティビティは、以下のカテゴリでフィルタリング可能です。

1. サイドバーで検索または移動からプロジェクトを検索
2. 管理 > アクティビティを選択
3. タブを選択してフィルタリング:
   • すべて: プロジェクトメンバーによるすべてのコントリビューション
   • プッシュイベント: プロジェクト内のプッシュイベント
   • マージイベント: 承認されたマージリクエスト
   • イシューイベント: オープン・クローズされたイシュー
   • コメント: プロジェクトメンバーによる投稿コメント
   • デザイン: 追加・更新・削除されたデザイン
   • チーム: プロジェクトに参加・離脱したメンバー

パフォーマンス上の理由から、3年以上前のアクティビティイベントは削除されます。

5. プロジェクトの編集と設定

5.1 プロジェクト名と説明の編集

プロジェクトの基本情報を編集できます。少なくともメンテナーロールが必要です。

1. サイドバーで検索または移動からプロジェクトを検索
2. 設定 > 一般を選択
3. プロジェクト名テキストボックスにプロジェクト名を入力
4. オプション: プロジェクト説明テキストボックスに説明を入力(最大2,000文字。CI/CDカタログで公開されるコンポーネントにはプロジェクト説明が必要です)
5. 変更を保存を選択

5.2 リポジトリ名の変更

リポジトリ名を変更すると、URLが変更されます。管理者またはメンテナー/所有者ロールが必要です。

重要な注意事項:

リポジトリパスを変更すると、古いURLにプッシュまたはプルを行った場合にユーザーに問題が発生する可能性があります。リダイレクトの期間とその副作用については、リポジトリ名変更時のリダイレクトに関するドキュメントを参照してください。

手順:

1. サイドバーで検索または移動からプロジェクトを検索
2. 設定 > 一般を選択
3. 高度な設定を展開
4. パスを変更テキストボックスでパスを編集
5. パスを変更を選択

5.3 プロジェクトアバターの追加

プロジェクトを視覚的に識別しやすくするため、アバターを追加できます。アバターを追加しない場合、GitLabはプロジェクト名の最初の文字をデフォルトのプロジェクトアバターとして表示します。

リポジトリにロゴを追加:

少なくともメンテナーロールが必要です。ファイルは200KB以下、理想的な画像サイズは192 x 192ピクセルです。

1. プロジェクトのルートディレクトリに、logo.png、logo.jpg、またはlogo.gifという名前のファイルをアップロード

プロジェクト設定でアバターをアップロード:

少なくともメンテナーロールが必要です。ファイルは200KB以下、理想的な画像サイズは192 x 192ピクセルです。画像は.bmp、.gif、.ico、.jpeg、.png、.tiffのいずれかの形式である必要があります。

1. サイドバーで検索または移動からプロジェクトを検索
2. 設定 > 一般を選択
3. プロジェクトアバターセクションでファイルを選択をクリック
4. アバターファイルを選択
5. 変更を保存を選択

6. プロジェクトの転送

6.1 転送の概要

プロジェクトを別のグループに転送することで、組織構造の変更に対応できます。

転送される要素:

プロジェクトコンポーネント:

• イシュー
• マージリクエスト
• パイプライン
• ダッシュボード

プロジェクトメンバー:

• 直接メンバー
• メンバーシップ招待

継承メンバーシップを持つメンバーは、転送先グループのメンバーでない限りアクセスを失います。プロジェクトは転送先グループから新しいメンバー権限を継承します。

その他の変更:

• プロジェクトパスが変更されるため、プロジェクトコンポーネントのURLを必要に応じて更新してください
• マッチするグループラベルが転送先名前空間に存在しない場合、イシューとマージリクエスト用に新しいプロジェクトレベルのラベルが作成されます
• プロジェクトにエピックに割り当てられたイシューが含まれ、そのエピックが転送先グループで利用できない場合、GitLabは転送先グループにエピックのコピーを作成します。同じエピックに割り当てられたイシューを持つ複数のプロジェクトを転送すると、GitLabは各プロジェクトに対して転送先グループにそのエピックの個別のコピーを作成します

警告:

転送プロセス中のエラーは、プロジェクトのコンポーネントやエンドユーザーの依存関係のデータ損失につながる可能性があります。

6.2 転送の前提条件

• 転送先グループに対して少なくともメンテナーロールが必要
• 転送するプロジェクトの所有者である必要がある
• グループで新規プロジェクトの作成が許可されている必要がある
• コンテナレジストリが有効なプロジェクトの場合:
  • GitLab.com: 同一トップレベル名前空間内のみ転送可能。1,000を超えるコンテナリポジトリを持つプロジェクトは転送不可
• プロジェクトにセキュリティポリシーが割り当てられていないこと(割り当てられている場合、転送時に自動解除)
• ルート名前空間が変更される場合、命名規則に従うnpmパッケージをプロジェクトから削除する必要があります。転送後、以下のいずれかを実行できます:
  • 新しいルート名前空間パスでパッケージスコープを更新し、プロジェクトに再公開
  • ルート名前空間パスを更新せずにパッケージを再公開(この場合、パッケージは命名規則に従わなくなり、インスタンスエンドポイントでは利用できなくなります)

6.3 転送の手順

1. サイドバーで検索または移動からプロジェクトを検索
2. 設定 > 一般を選択
3. 高度な設定を展開
4. プロジェクトを転送で、転送先の名前空間を選択
5. プロジェクトを転送を選択
6. プロジェクト名を入力し、確認を選択

転送後、プロジェクトの新しいページにリダイレクトされ、GitLabがリダイレクトを適用します。リポジトリリダイレクトの詳細については、リポジトリパス変更に関するドキュメントを参照してください。

6.4 サブスクリプション階層間の転送

GitLab.com PremiumまたはUltimateからGitLab Freeにプロジェクトを転送すると、以下の影響があります。

• プロジェクトアクセストークンが取り消される
• パイプラインサブスクリプションとテストケースが削除される

7. プロジェクトのアーカイブと削除

7.1 アーカイブの動作

アーカイブは、プロジェクトを読み取り専用にして、将来の参照用にデータを保存します。

アーカイブ時の変更:

• プロジェクトが非アクティブになり、Archivedバッジが表示される
• ほとんどの機能が読み取り専用になる(リポジトリ、イシュー、マージリクエスト、パッケージを含む)
• フォーク関係が削除され、フォークからのオープンなマージリクエストがクローズされる
• デプロイ済みPagesがカスタムドメインとともに削除される
• スケジュールされたCI/CDパイプラインが停止する
• プルミラーリングが停止する

7.2 アーカイブの手順

管理者またはプロジェクトの所有者ロールが必要です。

プロジェクト設定からアーカイブ:

1. サイドバーで検索または移動からプロジェクトを検索
2. 設定 > 一般を選択
3. 高度な設定を展開
4. プロジェクトをアーカイブセクションでアーカイブを選択

プロジェクト一覧から直接アーカイブ:

1. サイドバーで検索または移動を選択
2. すべてのプロジェクトを表示を選択
3. メンバータブでアーカイブするプロジェクトを見つけ、(⋮)を選択
4. アーカイブを選択

このアクションは他のリストページでも利用可能です。

7.3 アーカイブ解除の手順

アーカイブを解除すると、以下の変更が発生します。

• 読み取り専用制限が削除される
• プロジェクトが非アクティブとしてマークされなくなる
• スケジュールされたCI/CDパイプラインが自動的に再開される
• プルミラーリングが自動的に再開される

グループのアーカイブの一部としてアーカイブされたプロジェクトは、個別にアーカイブ解除できません。すべてのプロジェクトとサブグループをアーカイブ解除するには、親グループをアーカイブ解除する必要があります。

デプロイ済みPagesは自動的に復元されません。Pagesを復元するには、パイプラインを再実行する必要があります。

管理者またはプロジェクトの所有者ロールが必要です。

プロジェクト設定からアーカイブ解除:

1. アーカイブされたプロジェクトを見つける
   • サイドバーで検索または移動を選択
   • すべてのプロジェクトを表示を選択
   • 非アクティブタブでプロジェクトを選択
2. サイドバーで設定 > 一般を選択
3. 高度な設定を展開
4. プロジェクトのアーカイブ解除セクションでアーカイブ解除を選択

プロジェクト一覧から直接アーカイブ解除:

1. サイドバーで検索または移動を選択
2. すべてのプロジェクトを表示を選択
3. 非アクティブタブでアーカイブ解除するプロジェクトを見つけ、(⋮)を選択
4. アーカイブ解除を選択

このアクションは他のリストページでも利用可能です。

7.4 プロジェクトの削除

GitLab 18.0以降、デフォルトでプロジェクトは段階的削除プロセスを経ます。

前提条件:

• プロジェクトの所有者ロールが必要
• 所有者がプロジェクトの削除を許可されている必要があります

削除の手順:

1. サイドバーで検索または移動からプロジェクトを検索
2. 設定 > 一般を選択
3. 高度な設定を展開
4. プロジェクトを削除セクションで削除を選択
5. 確認ダイアログでプロジェクト名を入力し、はい、プロジェクトを削除しますを選択

このアクションは、プロジェクトを削除対象としてマークするバックグラウンドジョブを追加します。GitLab.comでは、プロジェクトは30日後に削除されます。

削除をスケジュールしたユーザーが削除が発生する前にプロジェクトへのアクセスを失った場合(例: プロジェクトから離脱、ロールのダウングレード、プロジェクトからの禁止)、削除ジョブは代わりにプロジェクトを復元し、プロジェクトは削除予定から外れます。

警告:

削除をスケジュールしたユーザーがジョブ実行前に所有者ロールまたは管理者アクセスを再取得した場合、ジョブはプロジェクトを完全に削除します。

7.5 プロジェクトの即座の削除

GitLab.comとGitLab Dedicatedでは、プロジェクトが削除された後、そのデータは30日間保持され、即座の削除は利用できません。GitLab.comでプロジェクトを即座に削除する必要がある場合は、サポートチケットを開くことができます。

設定された保持期間を待たずにプロジェクトを削除したい場合は、プロジェクトを即座に削除できます。

前提条件:

• プロジェクトの所有者ロールが必要
• プロジェクトを削除予定としてスケジュール済みである必要があります

手順:

1. サイドバーで検索または移動からプロジェクトを検索
2. 設定 > 一般を選択
3. 高度な設定を展開
4. プロジェクトを削除セクションで即座に削除を選択
5. 確認ダイアログでプロジェクト名を入力し、確認を選択

このアクションは、イシューやマージリクエストを含むプロジェクトとすべての関連リソースを削除します。

7.6 プロジェクトの復元

プロジェクトの所有者ロールが必要です。

手順:

1. サイドバーで検索または移動からプロジェクトを検索
2. 設定 > 一般を選択
3. 高度な設定を展開
4. プロジェクトを復元セクションでプロジェクトを復元を選択

8. アクションメニューによるプロジェクト管理

必要なプロジェクト権限を持っている場合、アクションメニューからプロジェクトを管理できます。

手順:

1. サイドバーで検索または移動 > すべてのプロジェクトを表示を選択
2. プロジェクトページでプロジェクトを見つけ、アクションメニュー(⋮)を選択
3. アクションを選択

プロジェクトの状態に応じて、以下のアクションが利用可能です。

プロジェクト状態	利用可能なアクション
アクティブ	編集、アーカイブ、転送、プロジェクトから離脱、削除
アーカイブ済み	アーカイブ解除、プロジェクトから離脱、削除
削除保留中	復元、プロジェクトから離脱、即座に削除

9. 移行時のセキュリティとベストプラクティス

9.1 信頼できるソースからのみインポート

信頼できないソースからプロジェクトをインポートすると、攻撃者が機密データを窃取する可能性があります。例えば、悪意のある.gitlab-ci.ymlファイルを含むインポートプロジェクトは、グループCI/CD変数を流出させる恐れがあります。

9.2 LFSオブジェクトを含むプロジェクトの移行

プロジェクトにLFSオブジェクトが含まれる場合、.lfsconfigファイルのURLホスト(lfs.url)がリポジトリURLホストと異なると、LFSファイルがダウンロードされません。移行前に設定を確認してください。

9.3 移行履歴の確認

すべてのプロジェクトインポートの履歴を確認できます。

1. GitLab.comにサインイン
2. サイドバー上部で新規作成(+)を選択し、新規プロジェクト/リポジトリを選択
3. プロジェクトをインポートを選択
4. 右上の履歴リンクを選択
5. エラーがある場合は、詳細を選択して確認

履歴には以下の情報が含まれます。

• 外部システムからインポートされた場合はソースプロジェクトのパス、GitLabプロジェクトが移行された場合はインポート方法
• 宛先プロジェクトのパス
• 各インポートの開始日
• 各インポートのステータス
• エラーが発生した場合のエラー詳細

履歴には、組み込みテンプレートまたはカスタムテンプレートから作成されたプロジェクトも含まれます。GitLabは、テンプレートから新しいプロジェクトを作成するために、URL経由のリポジトリインポートを使用します。

10. トラブルシューティング

10.1 インポートされたリポジトリにブランチが欠落している場合

インポートされたリポジトリにソースリポジトリのすべてのブランチが含まれていない場合:

1. 環境変数IMPORT_DEBUG=trueを設定
2. 異なるグループ、サブグループ、またはプロジェクト名で再インポート
3. それでもブランチが欠落している場合、importer.logを確認(jqなどで解析)

10.2 例外エラー: リポジトリのインポートエラー

tar.gz形式のリポジトリソースコードダウンロードファイルをインポートしようとすると、このエラーが発生します。インポートには、単なるリポジトリダウンロードファイルではなく、GitLabエクスポートファイルが必要です。

10.3 長期化または失敗したインポートの診断

特にS3を使用するファイルベースのインポートで、長期化または失敗が発生している場合、以下が根本原因の特定に役立ちます。

インポートステータスの確認:

1. GitLab APIを使用して影響を受けるプロジェクトのインポートステータスを確認
2. レスポンスのエラーメッセージまたはステータス情報、特にstatusとimport_error値を確認
3. レスポンスのcorrelation_idを記録(さらなるトラブルシューティングに必須)

ログの確認:

収集した情報を以下の一般的な問題と照合します。

• 中断されたジョブ: 高いinterrupted_countまたは失敗を示すjob_statusが表示される場合、インポートジョブが複数回中断され、デッドキューに配置された可能性があります
• S3接続性: S3を使用するインポートの場合、ログでS3関連のエラーメッセージを確認してください
• 大規模リポジトリ: リポジトリが非常に大きい場合、インポートがタイムアウトする可能性があります。この場合、直接転送の使用を検討してください

11. まとめ

GitLab.comへの移行は、適切な計画と理解があれば、スムーズに実行できます。プレースホルダーユーザー機能により、コントリビューションの正確な帰属を保ちながら、段階的な移行が可能になりました。CSV一括割り当てなどの機能を活用することで、大規模な移行も効率的に処理できます。

移行後のプロジェクト管理においても、アーカイブ、転送、削除といった操作が柔軟に行えるため、組織の変化に応じた適切なプロジェクト構成を維持できます。セキュリティのベストプラクティスを遵守しながら、GitLab.comの強力な移行・管理機能を最大限に活用してください。

特に重要なポイントは以下の通りです。

• プレースホルダーユーザー上限を事前に確認し、計画的に移行を実施する
• 再割り当てプロセスを完全に完了してから、プロジェクトの移動や構造変更を行う
• セキュリティ考慮事項を理解し、信頼できるソースからのみインポートする
• 移行履歴を定期的に確認し、エラーが発生した場合は早期に対処する

これらのベストプラクティスに従うことで、GitLab.comへの移行を成功させ、チームの生産性を最大化できます。