Cloud Build と Cloud Source Repositories を連携させる方法と課題点
こんにちは、クラウドエース SRE の荒木です。
Cloud Build と Cloud Source Repositories(以下 CSR) の連携について、方法や気になった点を備忘録的にご紹介します。
GitHub が使えない案件
最近担当した案件では、セキュリティ要件のため、GitHub リポジトリをソースコードの保管場所として利用することができませんでした。
この場合いくつかの解決策が考えられますが、今回は以下の考慮すべき点があったため、CSR を利用することにしました。
- 開発終了後のソースコードの改修作業は基本的に想定していない
- 新たにGitLabなどのバージョン管理システムを社内向けに構築するほど費用と時間をかけられない
- リポジトリに Terraform のソースコードを格納し、Cloud Build のトリガーの参照先に設定したい
Cloud Source Repositories とは?
あまり聞き慣れない方も多いかと思いますので、簡単に Google Cloud の CSR についてご紹介します。
CSR は Google Cloud 上で提供されているプライベート Git リポジトリサービスです。
Google Cloud 上で Git を使ったソースコードの共有やバージョン管理が可能になります。Git コマンドの標準セットに対応しているため、一般的な Git に慣れている方であれば、他のリポジトリサービスと同様の感覚で使用することができます。また、Cloud Build や App Engine、Compute Engine などの Google Cloud 上で動く他のサービスともスムーズに連携することが可能です。
ローカルリポジトリを介して、GitHub や Bitbucket 上にホストされるリポジトリに接続することもできます。
たとえば、GitHub のリモートリポジトリを origin として remote に登録してある($ git remote -v
で remote の一覧を確認できる)場合、CSR のリモートリポジトリを google として remote に登録する($ git remote add google <URL>
)のが一般的です。
CSR に格納したソースコードを Cloud Build でビルドする方法
案件では、CSR に保存された Terraform のソースコードを使って、Cloud Build が自動でビルドを行う仕組みを設定しました。ここでは、そのセットアップの手順を簡潔に説明します。
まだ CSR のリポジトリがなければ新規作成します。
今回は例として zenn-csr-terraform
というリポジトリを作成しました。
ローカルリポジトリをリモートとして追加しプッシュすることで、ソースコードをリポジトリにアップロードできます。
# リモートとして追加
git remote add google ssh://[EMAIL]@source.developers.google.com:2022/p/[PROJECT_ID]/r/[REPO_NAME]
# プッシュ
git push --all google
ローカル環境を一切使いたくない場合は、Cloud Shell からプッシュしてソースコードをリポジトリにアップロードすることも可能
つぎに、Cloud Build トリガーを設定するために、Cloud Build のリポジトリ管理画面に行きます。
すると、リポジトリのセクションに先程作成した CSR のリポジトリが表示されていると思います。
同じプロジェクトでリポジトリとトリガーを管理している場合、接続先の追加作業をすることなく自動で表示されるのは簡単でいいですね。
トリガーの名前やイベントなどを任意の値に設定し、ソースに CSR のリポジトリを選択します。
ここでは、特定のブランチへのプッシュを検知してトリガーが発火するように設定できます。
特にブランチの指定がない場合は画像のように .*
と入力すればすべてのブランチを監視するようになります。
これで CSR と Cloud Build の連携は完了です。
あとはブランチにプッシュするか、手動でトリガーを発火させれば、Cloud Build が構成ファイルの設定にしたがって実行されます。
Cloud Build の構成ファイルについての説明は主題とずれるため割愛します。
気になる方は公式ドキュメントをご参照ください。
現状の課題点
簡単にセットアップできる CSR ですが、ソースコードの格納先として活用するにあたっていくつかの課題点があります。
- プルリクエストなどのコードレビュープロセス機能がない
- イシュー管理機能がない
- UI が使いづらい
- Google Cloud のサービス以外との互換性が乏しい
共同開発している場合、ローカルリポジトリで開発した内容を main ブランチに反映する際には変更点のレビューが重要となりますが、CSR にコードレビュープロセスが組み込まれていないのはかなり気になるポイントだと思います。
(レビュー専用ブランチに一度プッシュして、それに対してコミットコメントでレビューするなどの方法はありますが...別のツールを使ったほうがコミュニケーションがとりやすいと思います)
イシュー管理機能がない点も同様で、総じて共同開発のための基盤が整っていない印象を受けてしまいます。
まとめ
現状、CSR を使用するのは、以下の場合に限られる気がします。
- プライベート Git リポジトリを手軽に利用したい
- GitHub や GitLab など、Google Cloud 外のサードパーティサービスの利用に制限がある
- 小規模な共同開発で、コードレビューやイシュー管理機能が必要ない
- Google Cloud のサービスとの連携がメインで、サードパーティサービスとの連携が必要ない
Google Cloud内のサービスとの連携のしやすさや、インフラ構築不要でプライベート Git を手軽に利用できる点などのメリットもありますので、ぜひ CSR の活用をご検討ください。
Discussion