技術部データ基盤チームの@zaimyです。
ペパボのデータ基盤チームでは、GitHub Enterprise Server（以下GHES）で運用していた全てのリポジトリをGitHub Enterprise Cloud（以下GHEC）へ移行しました。本記事では、移行の背景、実際の手順、そして注意すべきポイントについてまとめます。
移行の背景
ペパボではこれまでGHESを社内で運用してきましたが、GHECへの移行が決定しています。移行の背景には、利用者のメリットと運用のメリットの両面があります。
利用者のメリット
GHECへの移行により、以下のような新機能が利用可能になります。
- GitHub Codespaces: クラウドベースの開発環境
- Secret scanning: リポジトリ内の機密情報の自動検出
- GitHub Copilot: AI支援による開発効率の向上
また、クラウドサービスとして提供されるGHECは、GHESと比較して高い可用性とレスポンス速度が期待できます。
運用のメリット
運用面では、以下のメリットがあります。
- GitHub Enterprise UserのEntra IDによる一元管理
- GHESの運用負荷からの解放
- バージョンアップ作業
- サーバーメンテナンス
- インフラ管理
既に新規のサービス開発ではGHECのリポジトリを利用していますが、各事業部でサービス開発に用いているGHESのリポジトリ数が膨大なため、全社的な移行はこれからといった状況です。そこで、各事業部での移行に先鞭を付けるために、データ基盤チームがGHESで運用している全リポジトリをGHECへ移行することにしました。
移行前の準備
必要な権限の整理
移行作業を行うには、GHECのOrganizationで権限設定が必要です。具体的には以下のように権限を付与しました。
- GHEC OrganizationにMigrator roleを付与するためのチーム（
ghec-migration-maintainers）を作成 gh gei grant-migrator-roleコマンドでMigrator roleを付与- 移行作業を行うメンバーが所属するチーム（例：
data-team-engineers）の親チームをghec-migration-maintainersに設定
移行が完了したチームはghec-migration-maintainersから抜けることで、Migrator roleが自動的に剥奪されます。
ローカルストレージの設定
移行時にはアーカイブデータを保存するために任意のblobストレージが必要ですが、GHES 3.16以降ではクラウドストレージプロバイダーを必要とせず、GHESのローカルストレージに保存できます。
この設定はManagement ConsoleからGHES管理者が行えます。詳しくはドキュメントを参照ください。
Personal Access Tokenの準備
移行には2種類のPATが必要です。
- GHES側のPAT:
admin:org,repo - GHEC側のPAT:
repo,read:org,workflow
移行手順
GitHub Enterprise Importer CLIのインストール
gh extension install github/gh-gei
ソースリポジトリをGHEC移行できる状態にする
リポジトリによりますが、データ基盤チームでは主に以下の対応を行いました。GHESでは社内向けDocker RegistryにCI向けのコンテナイメージを保存して利用していましたが、GHECでは利用できないため、同等の環境をワークフロー中でパブリックなベースイメージから構築した上でキャッシュする構成としました。これにより、依存関係の追加やコンテナ中での設定の追加などワークフローを大幅に修正する必要がありました。
- GHESを前提とした実装の変更
- DependabotのassigneesやCODEOWNERSのユーザーIDの変更
- ドキュメントやコメントにハードコーディングされたURLの変更など
- GitHub Actionsのワークフローの変更
- GHESで提供される社内向けのコンテナイメージをパブリックなイメージに変更
- 付随して依存関係の追加、設定の追加、キャッシュの追加
- runnerの変更
- Google CloudやAWSに接続するためのWorkload Identity Providerの変更など
- GHESで提供される社内向けのコンテナイメージをパブリックなイメージに変更
ソースリポジトリのアーカイブ化
移行中に差分が発生することを防ぐため、GHES側のリポジトリを事前にアーカイブします。
移行の実行
移行はgh gei migrate-repoコマンドで実行します。以下は実行例です。
gh gei migrate-repo \
--verbose \
--github-source-org "source-org" \
--source-repo "source-repo" \
--github-target-org "target-org" \
--target-repo "target-repo" \
--ghes-api-url "https://git.example.com/api/v3" \
--target-repo-visibility internal
--queue-onlyオプションを付けると、ジョブをキューに追加した後、別途gh gei wait-for-migrationで待機できます。
マネキンの割り当て
移行後、GHES上のユーザーは「マネキン」として扱われ、Organization OwnerがGHEC側のユーザーアカウントとマネキンを紐付ける必要があります。この作業はユーザーごとに1度だけ実施すればよく、以降の移行では自動的に紐付けられます。
なお、マネキンの一覧を作成するために gh gei generate-mannequin-csv コマンドを実行しますが、この際に使用するPATはworkflowスコープを持つ必要があるため注意が必要です。
また、マネキンの割り当ては一度実行すると戻せないため、慎重に実施する必要があります。ペパボでは社員台帳をもとに、GHEC側のユーザーアカウントとGHES側のマネキンを対応付けるスクリプトが用意されました。
移行後の設定変更
移行が完了したら、種々の設定をGHEC側のリポジトリで更新します。データ基盤チームでは主に以下の設定を行いました。
- ブランチ保護のためのRulesetの設定
- Slack通知の設定（Slack Appの再設定）
- アクセス権限の設定
- GitHub Actionsで利用しているシークレットの再設定
移行されるデータと移行されないデータ
移行されるデータ
- Gitリポジトリ本体
- Issue
- Pull Request
- Releases
- Wiki
移行されないデータ
- GitHub Projects（プロジェクトボード）
- GitHub Actionsの実行履歴
- Packages
データ基盤チームではProjectsをスクラムのバックログとして利用しているため、GraphQL APIを使ってProjectsを移行するスクリプトを作成しました。
注意すべきポイント
社内向けgemの配信
GHESではプライベートレジストリを構成して配信していましたが、GHECではGitHub PackagesのプライベートGemとしてrubygems.pkg.github.com/target-repoから配信することになります。
publishに関しては、従来は社内向けのActionを用いていましたが、GHECではRelease Gem to GitHub Packages Actionを利用しています。
なお、gemに依存する主体からのアクセスは明示的に許可する必要があります。gemのPackage settingsから、アクセスを許可するリポジトリやチームを設定します。
また、gemに依存するリポジトリでDependabotを利用する場合、read:packagesスコープを持つPATをdependabot.ymlで指定する必要があります。secrets.GITHUB_TOKENでは認証できないため注意が必要です。
Rulesetによるブランチ保護とDependabotによるPRの自動マージ
ドキュメントの通り、GitHub Actionsを利用してDependabotによるPRを自動的にマージできます。
Rulesetによるブランチ保護でCode Ownersのレビューを必須にしているリポジトリでこの設定を行う場合、.github/CODEOWNERSでパッケージ管理ファイルで任意のactorをownerに設定し、GitHub Appのトークンでapproveする構成にする必要があります。トークンの生成にはCreate GitHub App Token Actionを利用できます。以下に例を示します。
# .github/CODEOWNERSの例
# 基本的には開発者をCode Ownersとする
* @user1 @user2
# パッケージ管理ファイルはCode Ownersを指定しない（任意のactorをCode Ownerとする）
pyproject.toml
poetry.lock
package-lock.json
name: Dependabot auto-merge
on: pull_request_target
permissions:
contents: write
pull-requests: write
jobs:
dependabot:
runs-on: ubuntu-latest
if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'my-org/my-repo'
steps:
- uses: actions/create-github-app-token@v2
id: app-token
with:
app-id: ${{ secrets.TOKEN_APP_APP_ID }}
private-key: ${{ secrets.TOKEN_APP_PRIVATE_KEY }}
- uses: dependabot/fetch-metadata@v2
id: metadata
with:
github-token: "${{ steps.app-token.outputs.token }}"
- name: Enable auto-merge for Dependabot PRs
if: |
steps.metadata.outputs.update-type == 'version-update:semver-patch' ||
steps.metadata.outputs.update-type == 'version-update:semver-minor'
run: |
gh pr review --approve "$PR_URL"
gh pr merge --auto --merge "$PR_URL"
env:
PR_URL: ${{ github.event.pull_request.html_url }}
GH_TOKEN: ${{ steps.app-token.outputs.token }}
新機能の活用
AI活用
GHESではClaude Code Actionsを利用していましたが、それに加えてGHECでは以下の機能が利用可能になりました。用途に合わせて活用しています。
- GitHub Copilot Coding Agent
- 1ユーザーとしてUIが統合されており、issueにCopilotをアサインする形で自然に利用できる
- GitHub Models
actions/ai-inferenceを利用して、GitHub Actionsから利用可能
Pull Requestの通知
レビューが必要なPRをSlackに通知する際、GHECでは条件にマッチするPRを定期的に通知するScheduled Remindersをorganization, repository, userごとに設定可能です。
まとめ
データ基盤チームでは、GHESからGHECへの移行を無事完了しました。移行自体はgh geiコマンドを使うことで比較的スムーズに進められましたが、移行後の設定変更やProjectsの移行など、細かい対応が必要な部分もありました。
GHECに移行したことで、最新のGitHub機能を活用できるようになり、開発体験の向上につながっています。
同様の移行を検討されている方の参考になれば幸いです。
