· CI/CD とソース管理  · 8 min read

Cloud Source Repositories を使ったソースコード管理

Google Cloud の Cloud Source Repositories を活用した効率的なソースコード管理と CI/CD パイプラインの構築方法

Google Cloud の Cloud Source Repositories を活用した効率的なソースコード管理と CI/CD パイプラインの構築方法

Cloud Source Repositories の基本

概要と特徴

Cloud Source Repositories（CSR）は Google Cloud の完全マネージド型 Git リポジトリサービスです。

  • プライベートGitリポジトリ
  • Google Cloud 製品との緊密な統合
  • IAMによるアクセス制御
  • ソースコード検索機能

主要機能

  1. バージョン管理

    • Gitベースの操作
    • ブランチ管理
    • タグ付け
    • コミット履歴

  2. セキュリティ機能

    • IAMとの統合
    • 暗号化保存
    • 監査ログ

リポジトリのセットアップ

新規リポジトリの作成

# リポジトリの作成
gcloud source repos create my-repository

# ローカルリポジトリの初期化
git init
git remote add google https://source.developers.google.com/p/YOUR_PROJECT_ID/r/my-repository

既存リポジトリのミラーリング

# GitHub/BitBucketからのミラーリング設定
gcloud source repos create my-mirror
gcloud source repos connections create github \
    --repository=my-mirror \
    --remote-uri=https://github.com/username/repo.git

CI/CD との統合

Cloud Build との連携

# cloudbuild.yaml
steps:
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['builds', 'submit', '--tag', 'gcr.io/$PROJECT_ID/myapp']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/$PROJECT_ID/myapp']

トリガーの設定

  1. プッシュトリガー

    • 特定ブランチへのプッシュ時
    • タグのプッシュ時

  2. プルリクエストトリガー

    • PRの作成時
    • PRの更新時

コードレビュープロセス

レビュー機能の活用

  1. インラインコメント

    レビューコメントの例:
- 行単位のコメント
- スレッド形式の議論
- 提案の追加

  2. プルリクエストワークフロー

    • レビュアーの割り当て
    • 承認プロセス
    • マージ条件の設定

セキュリティと認証

アクセス制御

役割と権限:
  roles/source.reader:
    - コードの閲覧
    - クローン作成
  roles/source.writer:
    - コードのプッシュ
    - ブランチの作成
  roles/source.admin:
    - リポジトリ管理
    - 権限設定

認証設定

  1. SSH認証

    # SSH鍵の生成
ssh-keygen -t rsa -b 4096 -C "your-email@example.com"

# 公開鍵の登録
gcloud compute project-info add-metadata \
    --metadata ssh-keys="$(cat ~/.ssh/id_rsa.pub)"

  2. OAuth認証

    • Googleアカウントとの連携
    • アプリケーション固有の認証情報

高度な機能の活用

コード検索

検索機能:
  構文検索:
    - ファイル名
    - コード内容
    - コミットメッセージ
  フィルター:
    - 言語
    - 日付範囲
    - 作成者

Pub/Sub 通知

通知設定:
  イベント:
    - プッシュイベント
    - プルリクエスト
    - コメント追加
  通知先:
    - Slack
    - メール
    - カスタムエンドポイント

リポジトリ構成の選択

モノレポとマルチレポの概要

  1. モノレポ（Monorepo）

    • 定義: 複数のプロジェクトやサービスのコードを1つのリポジトリで管理する方式
    • 具体例:
      my-company-repo/
├── frontend/
│   ├── web-app/
│   └── mobile-app/
├── backend/
│   ├── user-service/
│   └── payment-service/
└── shared/
    └── common-libraries/

  2. マルチレポ（Multi-repo）

    • 定義: プロジェクトやサービスごとに個別のリポジトリを作成する方式
    • 具体例:
      リポジトリ群:
- my-company/frontend-web
- my-company/frontend-mobile
- my-company/user-service
- my-company/payment-service

それぞれのメリット・デメリット

モノレポ方式

メリット:

利点:
  依存関係:
    - ライブラリのバージョン一元管理
    - 共通コードの共有が容易
  開発効率:
    - 横断的な変更が容易
    - コードの再利用性が高い
  CI/CD:
    - ビルドプロセスの統一
    - デプロイの整合性確保

デメリット:

課題:
  規模:
    - リポジトリサイズの肥大化
    - クローン時間の増加
  権限管理:
    - きめ細かな制御が困難
  ビルド:
    - CI時間の長期化

マルチレポ方式

メリット:

利点:
  独立性:
    - チーム単位での開発が容易
    - デプロイの独立性
  権限管理:
    - プロジェクト単位での細かい制御
  パフォーマンス:
    - クローンが高速
    - ビルド時間の最適化

デメリット:

課題:
  依存関係:
    - バージョン管理の複雑化
    - 共通コードの共有が困難
  運用:
    - リポジトリ数の管理負荷
    - CI/CD設定の重複

選択の判断基準

  1. 組織の規模

    • 小規模チーム → モノレポ
    • 大規模組織 → マルチレポまたはハイブリッド

  2. プロジェクトの性質

    • 密結合なサービス群 → モノレポ
    • 疎結合なサービス群 → マルチレポ

  3. 開発文化

    モノレポに適した文化:
  - 頻繁な共同作業
  - 統一的な開発プロセス
  - 強力な自動化体制

マルチレポに適した文化:
  - チーム単位の自律性重視
  - 独立したリリースサイクル
  - 多様な技術スタック

ブランチ戦略の選択とベストプラクティス

主要なブランチ戦略の概要

  1. Git Flow

    • 定義: 厳格に定義された長期ブランチと機能ブランチを使用する体系的な戦略

    • ブランチ構成:

      ブランチ種別:
  main: # または master
    - 本番環境のコード
    - 常にリリース可能な状態
  develop:
    - 開発用メインブランチ
    - 次回リリースの統合先
  feature/*:
    - 新機能開発用
    - developから分岐
  release/*:
    - リリース準備用
    - バージョン番号を冠する
  hotfix/*:
    - 緊急バグ修正用
    - mainから分岐

    • 適用例:

      • バージョン管理が必要なパッケージ開発
      • 複数バージョンの並行サポート
      • 大規模チームでの開発

  2. Trunk Based Development

    • 定義: すべての開発をメインブランチ（trunk）に直接マージする軽量な戦略

    • ブランチ構成:

      ブランチ種別:
  main: # trunk
    - すべての開発の統合先
    - CI/CDのトリガー
  feature/*:
    - 短期間の機能開発用
    - 数日以内にマージ

    • 適用例:

      • CI/CDを重視する組織
      • マイクロサービスアーキテクチャ
      • DevOps実践組織

  3. GitHub Flow

    • 定義: シンプルなフローとプルリクエストを重視した戦略

    • ブランチ構成:

      ブランチ種別:
  main:
    - デプロイ可能な唯一の長期ブランチ
    - 常に最新状態
  feature/*:
    - 機能開発やバグ修正用
    - プルリクエストでレビュー

    • 適用例:

      • WebサービスのCI/CD
      • オープンソースプロジェクト
      • 小規模チーム

戦略選択のガイドライン

  1. プロジェクト特性による選択

    Git Flow向き:
  - リリースサイクルが長い
  - 複数バージョンの並行管理が必要
  - QAプロセスが厳格

Trunk Based向き:
  - 継続的デリバリーを実践
  - 自動テストが充実
  - 小さな変更の積み重ね

GitHub Flow向き:
  - シンプルな開発フロー
  - 頻繁なデプロイ
  - コードレビュー重視

  2. チーム規模による考慮

    小規模チーム（5人以下）:
  推奨: GitHub Flow
  理由:
    - オーバーヘッドが少ない
    - コミュニケーションが容易

中規模チーム（5-20人）:
  推奨: Trunk BasedまたはGitHub Flow
  理由:
    - 適度な規律と柔軟性
    - 効率的な統合

大規模チーム（20人以上）:
  推奨: Git FlowまたはTrunk Based
  理由:
    - 明確なルール化
    - スケーラブルな管理

実装のベストプラクティス

  1. ブランチ命名規則

    feature/: 
  - feature/add-login
  - feature/JIRA-123
bugfix/:
  - bugfix/fix-memory-leak
  - bugfix/JIRA-456
release/:
  - release/v1.2.0
  - release/2024Q1

  2. コミットメッセージ規約

    形式:
  - type: feat, fix, docs, style, refactor
  - scope: 影響範囲
  - subject: 変更内容の要約

例:
  - feat(auth): add OAuth2 support
  - fix(api): resolve memory leak

  3. マージ戦略

    選択肢:
  merge:
    - 履歴を保持
    - ブランチの文脈を維持
  squash:
    - 履歴を一つに統合
    - クリーンな履歴
  rebase:
    - 直線的な履歴
    - コンフリクト解決が複雑

Cloud Source Repositories での実装

  1. ブランチ保護ルール

    保護設定:
  main:
    - プルリクエスト必須
    - レビュー承認必須
    - CIパス必須
  develop:
    - 直接プッシュ禁止
    - マージ前レビュー必須

  2. 自動化設定

    Cloud Build トリガー:
  プルリクエスト:
    - テスト実行
    - リンター実行
  マージ後:
    - デプロイパイプライン実行

監視とメンテナンス

メトリクス監視

監視項目:
  - リポジトリサイズ
  - クローン頻度
  - ビルド成功率
  - コミット頻度

定期的なメンテナンス

  1. クリーンアップ

    • 古いブランチの削除
    • 未使用タグの整理
    • 大きなファイルの最適化

  2. バックアップ

    • 定期的なミラーリング
    • メタデータのバックアップ
    • 復元手順の確認

参考リソース

公式ドキュメント：

Share:
Back to Blog

Related Posts