Cloud Source Repositories

解決する課題

Cloud Source Repositories は、かつてプライベート Git ホスティングを GCP の IAM やビルド基盤と統合して提供していました。現在の課題は新規採用ではなく、既存リポジトリと依存する自動処理を漏れなく発見し、代替先へ安全に移すことです。

• Git リポジトリを自前サーバーなしでプライベートにホストしたい
• リポジトリへのアクセス権を、別の認証基盤ではなく既存の GCP の IAM で一元管理したい
• コードの push を起点に Cloud Build で CI/CD を自動起動したい
• GitHub や Bitbucket のリポジトリを GCP 内にミラーリングして取り込みたい
• 誰がいつリポジトリを操作したかを GCP の監査ログとして残したい

主要概念と用語

• リポジトリ（repository）: Git のコード履歴を保管する単位。プロジェクトに紐づくプライベートな Git リポジトリとして作成する
• クローン（clone）: 標準の git クライアントでリポジトリを取得する操作。認証は gcloud 連携のヘルパーや SSH 鍵で行う
• ミラーリング（mirroring）: GitHub・Bitbucket の外部リポジトリの内容を、Cloud Source Repositories 側へ自動的に複製して同期する仕組み
• IAM ロール: リポジトリの閲覧・書き込み・管理などの権限を表すロール。ユーザーやサービスアカウントに付与してアクセスを制御する
• 認証ヘルパー（credential helper）: gcloud の資格情報を使って HTTPS で Git 認証を通す仕組み。GCP のログイン状態を Git の認証に流用できる
• ビルドトリガー連携: リポジトリへの push やタグ作成を起点に Cloud Build を起動する連携。CI/CD の入り口になる

仕様・制限・クォータ

• 標準の Git プロトコルに対応し、一般的な git クライアントからクローン・push・pull できる。HTTPS と SSH の両方の経路を利用できる
• 認証は GCP の IAM に統合され、リポジトリ単位・プロジェクト単位で権限を割り当てる
• 外部リポジトリのミラーリングに対応し、GitHub・Bitbucket を同期元にできる
• 利用実績がある組織の既存プロジェクトは当面利用できるが、未利用組織や組織に属さない新規プロジェクトは API を有効化できない
• リポジトリ内のコード検索やコミット履歴の閲覧をコンソールから行える
• 停止日は未公表だが少なくとも 1 年前に告知される。全リポジトリを停止日前に移行する前提で計画する

内部の仕組み

横にスクロール

既存の Cloud Source Repositories は、プロジェクトに紐づく Git 履歴を保持し、IAM で Git 操作を認可します。移行では git clone --mirror と git push --mirror で参照、全ブランチ、全タグを移した後、保存先以外の依存関係も切り替えます。

• クローンや push といった Git 操作は、gcloud の認証ヘルパーまたは SSH 鍵を介して認証され、その先で IAM ロールがアクセス可否を判定する
• 外部リポジトリをミラーリングすると、同期元の更新が Cloud Source Repositories 側へ反映され、GCP 内のリポジトリとして扱える
• リポジトリへの push などのイベントは Cloud Build のトリガーと連携でき、CI/CD パイプラインの起点になる
• リポジトリへの操作は Cloud Audit Logs に記録され、誰がいつアクセスしたかを追跡できる

AWS でいえば、マネージドなプライベート Git ホスティングを担う AWS CodeCommit が近い位置づけです。どちらもクラウドの IAM でアクセスを制御し、同じクラウド内の CI/CD サービス（Cloud Build／CodeBuild）と連携してパイプラインの入り口になります。

設計パターン / ベストプラクティス

• リポジトリへのアクセスは最小権限の IAM ロールで割り当て、閲覧だけでよい利用者に書き込み権限を与えない
• CI/CD で利用する場合は、サービスアカウントに必要最小限の読み取り権限だけを付与する
• 外部の GitHub などを正とする運用では、ミラーリングで取り込む構成にして同期元と取り込み先の役割を明確にする
• push を起点に Cloud Build トリガーを組み、ビルド・テスト・デプロイを自動化する
• 機密値や鍵はリポジトリにコミットしない。シークレットは Secret Manager で管理し、コードから分離する
• 新規構築では後継サービス（Secure Source Manager）や外部リポジトリ連携を含めて選定し、提供状況を踏まえた設計にする

運用・監視

• リポジトリへのアクセスや設定変更は Cloud Audit Logs に記録され、誰がいつ操作したかを監査できる
• push を契機にした Cloud Build の実行履歴を追うことで、コード変更から後続処理までの流れを可観測にする
• ミラーリング利用時は同期の成否を確認し、同期元と取り込み先の差分が放置されないようにする
• アクセスできない・push が拒否されるといった事象の典型原因は IAM ロールの不足で、付与ロールを見直して切り分ける
• コミット履歴やコード検索をコンソールから使い、変更の追跡や調査に役立てる

コスト

販売終了したサービスの過去料金を新規見積もりの基準にしません。移行先のリポジトリ、接続機能、保存容量、転送量に加え、再接続する Cloud Build やログの料金をまとめて比較します。

セキュリティ

• アクセス制御は GCP の IAM に統合される。リポジトリ単位・プロジェクト単位で最小権限のロールを割り当てる
• CI/CD から参照するサービスアカウントの権限を絞り、不要な書き込み権限を与えない
• 認証は gcloud の認証ヘルパーまたは SSH 鍵で行い、資格情報の管理を徹底する
• シークレットや鍵をリポジトリにコミットしない。機密値は Secret Manager から実行時に読み込む
• リポジトリへの操作を Cloud Audit Logs で監査し、不審なアクセスや権限変更を追跡できるようにする

関連サービス・比較

Cloud Source Repositories は単体で完結するというより、Cloud Build（CI/CD） や IAM（アクセス制御）、Cloud Logging（監査） と連携して開発フローの入り口を担います。AWS では、マネージドなプライベート Git ホスティングを担う AWS CodeCommit が最も近い位置づけです。

ハンズオン / CLI例

# 既存利用組織で移行対象を棚卸しする
gcloud source repos list

# 全参照・タグを含む移行用ミラーを取得する
gcloud source repos describe my-app --project=PROJECT_ID
git clone --mirror \
  https://source.developers.google.com/p/PROJECT_ID/r/my-app
cd my-app.git

# 移行先を設定し、全参照を送信する。URLは作成済みの移行先を指定する
git remote set-url --push origin TARGET_GIT_URL
git push --mirror

# 送信後にブランチ・タグ・既定ブランチを比較し、
# Cloud Buildトリガー、Webhook、IAM、非公開接続を移行先へ付け替える