この記事では、Cloud Buildを使ったCI/CDの仕組みと、そこから学んだ「自動化の本質」について紹介します。
もし「CI/CDって難しそう」「自分にはまだ早い技術かもしれない」と感じているなら、この記事が少しでも不安を和らげるきっかけになれば嬉しいです。
インターンに参加する前、CI/CDや自動化という言葉に対して、どこか距離を感じていました。
- CI/CDという言葉は知っていましたが、
- インフラエンジニアが扱うもの
- 大規模プロジェクト向けの仕組み
- 自分にはまだ早い領域
という印象がありました。
CI/CDとは、コードの変更後に行うビルドやテスト、デプロイを自動化する仕組みのことです。最初は仕組みの全体像がつかめず、不安もありました。
しかし、プロジェクトに関わる中で、自動化は特別な技術ではなく、安全に開発を進めるための基本設計であることに気づきました。
Cloud Buildで実現したこと
プロジェクトでは、Google CloudのCloud Buildを使用してCI/CDの仕組みを構築していました。
Cloud Buildは、GitHubへのpush（変更したコードをGitHubに反映すること）やPull Requestをトリガーにして、定義された処理を自動実行するサービスです。
実際に構築していた流れは次の通りです。
- GitHubへpush
- Cloud Buildが自動起動
- ビルド
- コンテナイメージ（アプリを動かすためのパッケージのようなもの）作成
- 開発環境または本番環境へデプロイ（作成したアプリをサーバーに反映すること）
重要なのは、「自動で動く」という表面的な部分ではありません。
実行タイミングが固定されていること
人の判断で「やる・やらない」を決めるのではなく、pushやmerge（別のブランチの変更を統合すること）というイベントに紐づいて処理が実行されます。これにより、実行漏れが発生しません。
手順がコードとして管理されていること
Cloud Buildでは、cloudbuild.yaml に処理を定義します。
ビルドやデプロイの手順がコードとして保存されるため、誰が実行しても同じ結果になるという再現性があります。
実行ログが残ること
いつ、どのコミットをデプロイしたのかが記録されます。
これはトラブル発生時の追跡に直結します。単なる便利機能ではなく、安全性を高める重要な要素です。
手動デプロイとの違い
自動化の価値は、手動運用と比較すると明確になります。
手動運用の場合に起こり得ること
- 古いコードでビルドしてしまう
- デプロイ対象のブランチ（コードを分けて管理する仕組み）を間違える
- 手順の一部を飛ばす
- 環境変数の設定を誤る
どれも珍しいミスではありません。
一方でCloud Buildを使うと、
- 決められたブランチのみが本番に反映される
- 定義された手順以外では処理が進まない
という状態を作れます。
これは単なる効率化ではなく、人間の注意力に依存しない設計です。
develop / main 分離とトリガー設計
プロジェクトでは、ブランチを分けて運用していました。
develop：開発用main：本番用
Cloud Buildのトリガー（特定の条件で処理を開始する仕組み）も、ブランチごとに設定されています。これにより、
- 開発途中のコードが本番に出ることを防ぐ
- 本番反映は意図的なmergeを通過したものだけに限定する
という設計が可能になります。
「本番は慎重に」というルールを口頭で徹底するのではなく、構造として間違えにくい状態を作ることが重要です。
Cloud Buildがもたらしたもの
Cloud Buildを導入したことで得られたのは、単なる自動実行ではありません。
1. 再現性
ビルド手順が常に同じであること。
2. 追跡性
誰がいつ何をデプロイしたかを確認できること。
3. 安全性
テストやビルドが通ったものだけが公開されること。
これらはすべて、「事故を減らす設計」に直結しています。
自動化の本質
自動化は、派手な技術ではありません。しかし現場で重要なのは、
- ミスを前提に設計すること
- 人間の判断を仕組みに置き換えること
- 再現可能な手順を持つこと
です。
最初はCI/CDの意味すら曖昧だった私でも、設計の意図を理解し、仕組みの一部に関わることができました。インターンを通して、この考え方に触れられたことは大きな学びになっていると思います。