こんにちは。DevOpsの深淵を歩むエンジニア諸君。
GitHubからBitbucketへの移行を検討しているということは、おそらく組織のセキュリティ要件の変化や、Jira/ConfluenceといったAtlassianエコシステムとの深い統合を求めている段階ですね。非常に賢明な判断です。
「リポジトリを移動させるだけ」と高を括っていると、必ずCI/CDが壊れ、デプロイが止まり、チームが混乱する日が来ます。今日は、「現場で絶対に事故を起こさないための、プロの移行戦略」を伝授しましょう。
—
1. なぜ「インポート機能」だけでは不十分なのか？
BitbucketにはGitHubリポジトリを一撃でインポートする便利な機能があります。しかし、本番環境の移行において、単なる「ミラーリング」は無意味です。「移行は、負債を捨てる最大のチャンス」であると心得てください。
移行すべきはコードだけではありません。以下の3要素をセットで移行する設計が必要です。
1. 履歴の継承: コミットログだけでなく、タグやブランチ構成の正確な維持。
2. 自動化の継承: GitHub ActionsからBitbucket Pipelinesへのロジック変換。
3. フックの継承: WebhookやAPI連携の再マッピング。
—
2. 安全かつ完璧な移行ステップ：完全チェックリスト
ステップ1：クリーンな移行のための「ベアミラーリング」
Bitbucketの画面ポチポチだけで済ませず、CLIを使ってローカルに一度「正本」を落としましょう。これにより、GitHub側の設定ミスや不整合を排除できます。
1. GitHubからベアクローン（全ブランチ・全タグを完全コピー）
git clone –mirror https://github.com/organization/repo.git
cd repo.git
2. リモートURLをBitbucketに変更
git remote set-url –push origin https://bitbucket.org/workspace/repo.git
3. Bitbucketへ強制プッシュ（これで履歴が完全に再現されます）
git push –mirror
ステップ2：CI/CD（GitHub Actions → Pipelines）の書き換え
これが最も骨の折れる作業です。GitHub ActionsのYAMLをBitbucket Pipelinesの`bitbucket-pipelines.yml`へ変換します。
【ポイント】
GitHub Actionsの「アクション」という概念はBitbucketにはありません。代わりに「Dockerコンテナベース」の実行になります。
bitbucket-pipelines.yml の極小例
image: node:18 # コンテナを指定
pipelines:
default:
- step:
name: Build and Test
caches:
- node
script:
- npm install
- npm test # テストが失敗すればここでパイプラインは止まる
ステップ3：Webhookの断捨離と再設定
GitHubで設定していたWebhookは、そのままでは動きません。
特に重要なのは「誰がトリガーするか」です。Bitbucketの管理画面から、Webhooks設定を行い、ペイロードの形式が受信側に適しているか必ず確認してください。
—
3. 動作確認：HelloWorldならぬ「Pipeline-World」
移行が完了したら、必ず以下のチェックを行ってください。これを飛ばすと、金曜の夜にトラブルが発生します。
1. 権限の疎通確認: `git clone` がSSH鍵で問題なく行えるか。
2. パイプラインの初回実行: 空のコミット（`git commit –allow-empty -m “Trigger build”`）をプッシュし、CIが正常に回るか確認。
3. Jira連携: リポジトリとJiraチケットのID（例：PROJ-123）がリンクし、コミットログからチケットへ飛べるか確認。
—
4. 先輩エンジニアからのアドバイス：移行を成功させる「心構え」
初心者が陥りやすい罠は、「移行した瞬間にすべてを切り替える」ことです。
段階的な移行（Canary Migration）を推奨します。
- リードタイムを確保する: 全員が一斉にBitbucketを使い始めると、CI設定の不備で全員の作業が止まります。まずは特定のチーム、特定のプロジェクトから小規模に移行してください。
- CIのキャッシュを意識する: GitHub ActionsよりもBitbucket Pipelinesはキャッシュの管理が重要です。`caches`設定を適切に行うだけで、ビルド時間が半分以下になることもあります。
まとめ
移行作業は、ツールを引っ越すだけでなく、チームの「CI/CDの作法」を再定義する絶好の機会です。今回紹介した手順をベースに、あなたのプロジェクトの構成に合わせてカスタマイズしてみてください。
「面倒だな」と思った時こそが、自動化の余地がある場所です。この移行が、あなたのチームの開発体験を劇的に加速させるきっかけになることを確信しています。
何か詰まったら、いつでも聞いてください。我々エンジニアは、常に「より良い自動化」のためにここにいるのですから。