01. 全体像 ─ コミット → ビルド → デプロイ
一人で書いていたコードを、複数人で安全に育てていくには「個々の変更をどう取り込み、どうリリースまで届けるか」の取り決めが必要です。チーム開発の標準ワークフローと、それを支える 3 つの自動化（CI / CD / IaC）を整理します。
なぜ「取り決め」が必要か
個人開発では、自分のローカル PC から本番サーバーに直接ファイルを置いても誰も困りません。しかし複数人になると次の問題が一気に噴き出します。
- 誰の変更がいつ入ったのか追えない
- 同じ箇所を別々に直して衝突する
- 動作確認が「自分のPC では動いた」止まり
- 本番に壊れたコードが入ってもロールバックできない
この 4 つの問題を仕組みで解決するのが「Git によるコミット → PR によるレビュー → CI によるビルド・テスト → CD による自動デプロイ」という標準ワークフローです。
標準ワークフロー（4 ステップ）
コミットとは何か
コミット (commit) は「いつ、誰が、何を、なぜ変えたか」を 1 つの単位で記録すること。Git の最小単位です。
- 小さく、意味のある単位で切る（1 つの目的に 1 コミット）
- 動く状態で切る（壊れた途中状態を残さない）
- メッセージで「なぜ」を残す（「何を」はコードを見ればわかる）
チームでは、feature ブランチに細かくコミットを積み、まとめて Pull Request として提出します。
ビルドとは何か
ビルド (build) は、ソースコードを「実行可能な成果物」に変換する工程。
| 言語 / 用途 | ビルド成果物 |
|---|---|
| Go / Rust | 実行バイナリ |
| Java / Kotlin | JAR / WAR |
| JavaScript フロント | バンドルされた JS / CSS / HTML |
| Python | そのまま実行（依存解決 + パッケージング） |
| コンテナ | Docker イメージ |
| Terraform | terraform plan の結果 |
チーム開発では、ビルドは 毎回 CI サーバーで自動実行 します。手元で「動いた」を信用せず、クリーンな環境でビルドできることを保証します。
デプロイとは何か
デプロイ (deploy) は、ビルドした成果物を「実際の利用環境に配置」する工程。チーム開発では通常、複数の環境を段階的に通します。
feature → 開発環境 (dev) → ステージング (stg) → 本番 (prod)
↑ ↑
QA / 動作確認 最終承認後に反映環境ごとに「何が動いていいか」を厳密に分け、prod へのデプロイは main へのマージ や タグ付け をトリガに、手動承認を挟んで実行することが多いです。
CI と CD の境目
| 用語 | 正式名 | やること | いつ動くか |
|---|---|---|---|
| CI | Continuous Integration | コードを取り込んで、自動でビルド・テスト | PR 作成 / push の度 |
| CD | Continuous Delivery / Deployment | 成果物を環境に配置 | main マージ後など |
「CI = ここまで自動で品質チェック」「CD = ここから自動でリリース」と分けて考えると整理しやすい。両方を 1 つのワークフローに書くことも多いですが、責務は別です。
3 大原則
- PR 単位で誰でも差し戻せる ── 一人で進めず、必ず他者の目を通す
- 自動テストが落ちたらマージできない ── 仕組みで品質を担保
- main は常にデプロイ可能 ── いつでも本番に出せる状態を保つ
これら 3 つを満たすツールとして、GitHub Actions / AWS CodePipeline / Azure Pipelines / Google Cloud Build が使われます。次の章から、各クラウドでどのサービスを組み合わせるかを見ていきます。