はじめに
TRIAL&RetailAI Advent Calendar 2024の22日目の記事になります。昨日は@k-yoshigaiさんの『インテグレーションテストをもっと楽に!Testcontainers はじめました』という記事でした。
私もIntegration Testを行った時にDBの切り替えがめんどくさいと感じたことがありますが、Testcontainersを使うと、ローカル環境や事前に設定したテスト用データベースを用意する必要がなくなるので非常に便利だなぁと感じました。
ぜひ試してみたいです。
本日のテーマは「GitHub移行した時の注意点・直面した課題とその対策」です。現在参画しているプロジェクトでは元々GitLabを使っていたのですが、最近GitHubに移行しました。移行作業を行うときに時に気をつけた点や、直面した課題と実際にどのような対策を行なったのか共有したいと思います。
自己紹介
基盤システム部に所属して、主にバックエンドの開発を行っております。
GitLabからGitHubへの移行計画
当たり前といえば、当たり前ですが、GitLabからGitHubに移行するにあたり移行計画を立てました。
いつ実施するのかや、CI/CD周りのアーキテクチャ、GitLabからGitHubへ移行する時に必要な権限の整理を行いました。
平日はチーム内で開発作業が行われていたため、移行作業を平日に行うことが難しいと判断して、休日の土曜日に行う計画を立てました。
GitHub移行の実施
ここから実際に行った移行作業についてまとめていきたいと思います。
実は直前まで気づかなかったのですが、移行に際してgit push
コマンドを使うので、それがCI/CDのトリガーを引き起こすのではないかとの指摘がチームからありました。
上記を踏まえて以下の手順でGitLabからGitHub移行を行いました。
1. GitLabとGitHub、その他必要な権限を付与してもらう。
実際に移行を行う前に必要な権限を管理者から付与してもらいました。
Git Labはowner
の権限を、GitHubではMaintainer
の権限を移行作業を行った時は付与してもらいました。
また、チーム内でCIツールであるGoogle CloudのCloudBuildを使っていたためCloudBuildの編集者権限を付与していただきました。
2. git push
によるCIのトリガーを無効にする
チームからの指摘事項を踏まえた結果、CloudBuildのCIを無効にしました。なるべく移行に伴うリスクを最小限にするためです。CloudBuildを使用している場合は、Google Console
からCloudBuild
を選択して縦3点バーをクリックすると無効にする
が出てくるので押下して無効にしました。
3. 移行するGitLabのリポジトリを--mirror
オプションでローカルにclone
する
ここからようやくより具体的な作業になります。
移行するGitLabのリポジトリを--mirror
オプションでローカルにclone
しました。
# Example
git clone --mirror "clone URL"
cd your-gitlab-repo.git
ここでclone
したGitLabのリポジトリにディレクトリを切り替えて、branch
やtag
等の確認を行いました。念のために、branch
やtag
をテキストファイルに出力しました。
# ブランチの確認。一応テキストファイルに保存
git branch -a >> branches.txt
# タグの確認(タグは使用していないので今回はテキストファイルの出力は省略)
git tag
4.remoteをGitHubに変更する
Git Hub
のリポジトリへ移行するためにremote
を切り替えました。
# 現在のリモートを確認(GitLab)
git remote -v
# 移行するGitHubのリポジトリのremoteのURLに切り替え
git remote set-url origin "new remote URL"
# remoteの切り替えが行われたか確認(GitHub)
git remote -v
ここまで来れば、あとはリポジトリをGitHub
にpush
するだけです。
5.リポジトリをGitHub
にpush
する
以下のGit
コマンドでGitHub
にpush
を行ないました。
git push --mirror github
このコマンドを実行した時点でエラーがでました。
エラー内容としては100MBを超えたファイルがあったことで、上記コマンドでpush
することができませんでした。
解決策
git filter-repo
をコマンド使用して解決しました。
リポジトリのREADME
のuser manual
に以下の説明が記述されています。
Rapidly rewrite entire repository history using user-specified filters. This is a destructive operation which should not be used lightly; it writes new commits, trees, tags, and blobs corresponding to (but filtered from) the original objects in the repository, then deletes the original history and leaves only the new. See [DISCUSSION] for more details on the ramifications of using this tool. Several different types of history rewrites are possible; examples include (but are not limited to):
- stripping large files (or large directories or large extensions)
...
重要なところをピックアップすると...
-
このコマンドを使った操作はユーザーが指定したルールに従ってリポジトリ全体の履歴を書き換えるもの
-
破壊的な操作(一度実行すると元の履歴は完全に消える)
-
使用例の1つとして、大きなファイル(または大きなディレクトリや特定の拡張子のファイル)を取り除く
使用する場合は、このコマンドを使用することが適切か考えて使用する必要があります。使い方を誤るとかなり影響がでてしまいます。
今回の場合、エラーメッセージとともに100MBを超えていたファイルがCUI上に表示されていました。そのファイルの拡張子等を確認して特段問題なさそうだったので、以下のコマンドを実行しました。
GitHub
# MacBookを使用しているのでHome Brewを使ってパッケージをインストール
brew install git-filter-repo
# 以下のコマンドで大きなファイルサイズを取り除く
git filter-repo --path <oversized file name> --invert-paths
その後...以下コマンドを実行
git push --mirror --force
この手順で無事にGit Lab
からGit Hub
への移行ができました。
後は、チームにremote
の切り替え手順を共有して、CloudBuildを有効にして、無事に影響なく移行作業を完了させることができました。
6. Git Lab
をアーカイブモードに設定する
Git Hub
からGit Lab
に移行が完了したので、Git Lab
のプロジェクトをアーカイブしました。こうすることで Git Lab
側では読み取り操作(例:リポジトリのクローン、ブラウジング、イシューの閲覧など)だけしか行われないので、移行後の万一の運用事故をなくすことができます。
Git Lab
のアーカイブモードの設定のやり方は公式ドキュメントの以下のページをご確認ください。
まとめ
Git Lab
からGit Hub
への移行についてまとめてみました。
あくまで今回行ったのは私が従事しているプロジェク内で行ったものになるので別のCI/CDのアーキテクチャ上ではうまくいかない可能性があります。もし移行を考えている方がいましたら各プロジェクトのCI/CDのアーキテクチャに合わせて移行手順を考えていく必要があると思います。
この記事がGit Lab
からGit Hub
に移行する際の参考になれば幸いです。
最後に
次回は@takudooonさんによる『🎄X'masにRustで南無阿弥陀仏🙏』です。
ぜひお楽しみに!!
RetailAIとTRIALではエンジニアを募集しています。
Kotlin、Flutter、Go、Python、他いろいろな言語を扱っています。
興味ある方は以下から確認してもらうか、メッセージをいただければと思います。