開発基盤・CI/CD
コードの変更を、壊さずに本番へ届ける仕組み
「書いた」と「動いている」の間をつなぐベルトコンベア。履歴・検証・配信の3つを担う。
最初に触るなら
Git ：分散型バージョン管理システム。全履歴を手元に持ち、ほぼ全操作がローカル
すべての開発の前提。履歴を残し、失敗したら戻せる状態を作ってから他の分野を学ぶ。次に GitHub、その次に GitHub Actions の順。
隣の分野とのつながり
| 分野 | どうつながるか |
|---|---|
| 実行基盤・ホスティング | 届け先。検証（CI）に通った変更を、実行基盤へ配信（CD）する |
| 監視・可観測性 | 配信したあとに壊れていないかを見る監視と、いつも組で使う |
| 自動化・連携 | CI の定期実行は、テスト以外の自動化にも使える |
| 実行基盤・ホスティング （から見ると） | 変更をここへ届けるのが開発基盤（CI/CD）の仕事 |
| 監視・可観測性 （から見ると） | 配信のたびに「壊れていないか」を見る習慣と組で使う |
| 自動化・連携 （から見ると） | CI の定期実行（スケジュール）も自動化の一種として使える |
この分野を理解する
まず履歴を残す。 Git はファイルの変更履歴を記録する道具で、「昨日の状態に戻す」「誰がどこを変えたか見る」ができる。GitHub はその履歴を置いて共有する場所で、他人と協力する入口でもある。この2つは他のすべての分野の前提になる。
CI と CD。 CI（継続的インテグレーション）は、変更を push するたびに自動でテストやビルドを走らせ、壊れていないか確かめる仕組み。CD（継続的デリバリー）は、確かめた変更を自動で実行基盤へ配信する仕組み。GitHub Actions は両方に使える。
環境もコードで書く。 サーバーやデータベースを画面からポチポチ作ると、同じものをもう一度作れない。Terraform のような道具は、環境の構成をコードで書いて再現できるようにする。個人開発では後回しでよいが、「手作業で作った環境は再現できない」という問題があることは知っておく。
隣の分野との境界。 配信先が「実行基盤」、配信後の見守りが「監視」。開発基盤は流れを自動化する役で、動かす場所そのものではない。
最初の一歩。 Git でコミットし、GitHub に push する。次に GitHub Actions で「push のたびにビルドが通るか」を確かめるワークフローを1つ置く。
この分野のツール（6件）
種別（自分で書く土台か、借りて使うサービスか）で分けている。「主要制約」は各ツールで最も先に当たる限界。
フレームワーク（1件）自分で書くコードの土台になるライブラリ。動かす場所は自分で用意する
| ツール | 学習 | 料金 | 成熟 | 主要制約 | 検証 |
|---|---|---|---|---|---|
| Playwright Chromium/Firefox/WebKitを1つのAPIで自動操作するE2Eテストフレームワーク | 中 | 無料 | 安定 | 対応Node.jsバージョン：最新の 22.x, 24.x, 26.x 系のいずれか |
ツール（2件）自分の環境にインストールして使うソフトウェア。無料のものが多いが、運用は自分で持つ
| ツール | 学習 | 料金 | 成熟 | 主要制約 | 検証 |
|---|---|---|---|---|---|
| Git 分散型バージョン管理システム。全履歴を手元に持ち、ほぼ全操作がローカル | 中 | 無料 | 安定 | 履歴に入れたファイルの永続性：clone は「プロジェクトの全履歴、すべてのファイルのすべての版」を取得する。一度コミットした大きなファイルは、次のコミットで削除しても、以後すべてのクローンがダウンロードし続ける | |
| Terraform クラウド資源を HCL で宣言し、差分を計算して適用する IaC ツール | 中 | 無料 | 安定 | ライセンス（Terraform 1.6.0 以降）：Business Source License 1.1。本番利用を含む利用は可だが、IBM の有償版と競合するホスト型・組み込み型での第三者提供は不可。各版は公開から4年後に MPL 2.0 へ移行 |
マネージドサービス（3件）事業者が運用していて、借りて使うサービス。運用を任せられる代わりに、プランの上限が乗る
| ツール | 学習 | 料金 | 成熟 | 主要制約 | 検証 |
|---|---|---|---|---|---|
| GitHub Git リポジトリのホスティングに PR・Issue・CI を統合した開発基盤 | 低 | 無料枠あり | 安定 | 1ファイルのサイズ上限：100 MiB を超えるファイルは push がブロックされる。50 MiB 超で警告。ブラウザからの追加は 25 MiB まで。超える場合は Git LFS を使う | |
| GitHub Actions GitHub リポジトリの push・PR・スケジュールで動く CI/CD 実行基盤 | 低 | 無料枠あり | 安定 | ジョブ実行時間の上限：6時間 / ジョブ（GitHub ホストランナー）、5日 / ジョブ（セルフホストランナー）。ワークフロー全体は 35日でキャンセル | |
| GitLab リポジトリ管理からCI/CDまでを一体化したDevOpsプラットフォーム | 中 | 無料枠あり | 安定 | Free プランのCI/CD compute minutes上限：400分 / 月（GitLab.com の Free namespace、共有Runner使用分） |
どれを選ぶか
| ツール | 種別 | どういう時に選ぶか／避けるか |
|---|---|---|
| Playwright | フレームワーク | ブラウザ経由のE2Eテストや、JavaScript実行が必要な動的サイトのスクレイピングでは第一候補。静的HTMLの取得だけならブラウザ起動が不要な軽量ライブラリのほうが高速。CI環境のNode.jsバージョンやOSが対応範囲外の場合は、先にランナー環境を合わせる必要がある |
| Git | ツール | ソースコードとテキスト設定の履歴管理では事実上の既定解で、代替を検討する場面はほぼない。避けるのは、頻繁に更新される大きなバイナリ（動画・データセット・ゲームアセット）を本体に入れる運用で、この場合は LFS かオブジェクトストレージに本体を置き、Git には参照だけを残す |
| Terraform | ツール | 複数のクラウド資源を再現可能に管理し、変更を差分レビューしてから適用したいなら第一候補。プロバイダーの広さで他の IaC ツールに勝る。避けるのは、Terraform を内包した製品を販売する場合（BSL の競合条項）と、1〜2個の資源を一度作るだけで変更管理が不要な場合（コンソールや CLI のほうが早い） |
| GitHub | マネージドサービス | 個人・チームのソースコードをホストし、Pull Request でレビューを回す用途では第一候補。無料プランで私有リポジトリも無制限に持てる。避けるのは、大きなバイナリ資産を本体に入れる運用（LFS 帯域と 100 MiB 上限に当たる）と、社外に一切データを出せない場合（Enterprise Server か自前ホスティングへ） |
| GitHub Actions | マネージドサービス | GitHub にコードを置いているなら、テスト・ビルド・デプロイの自動化では第一候補。公開リポジトリなら無料で上限も緩い。避けるのは、時刻厳守の定期実行（schedule は遅延する）、6時間を超える処理、常駐プロセス、そして私有リポジトリでの macOS ビルドの大量実行（分数課金が跳ねる） |
| GitLab | マネージドサービス | 小規模チームでリポジトリ管理とCI/CDを単一プラットフォームで完結させたい場合の候補。自己ホストへの移行や統合ツールチェーンを重視するならGitLabを選ぶ。Free枠のCI/CD分数（400分/月）やユーザー数（5人）に早期に到達する場合は、GitHub+Actionsの組み合わせや上位プランへの移行を検討する |
この分野が担う目的
目的ごとのページでは、他の分野のツールも含めて横断比較できる。
- ソースコードの履歴を管理し共同編集する （この分野から 3件）
- テストとビルドを自動実行する （この分野から 2件）
- 変更を自動で本番へ配信する （この分野から 2件）
- 定期的に処理を実行する （この分野から 1件）
- 大量データを一括処理する （この分野から 1件）
- 複数の処理を依存順に実行・再実行する （この分野から 1件）
- イベントや Webhook を受けて処理を起動する （この分野から 1件）
- ブラウザ操作を自動テストする （この分野から 1件）
- Web ページからデータを取得する （この分野から 1件）
- HTTP API を呼び出す （この分野から 1件）
- インフラをコードで定義・再現する （この分野から 1件）