「本番反映は
手動デプロイの典型的な事故パターン
- ファイルの
上 — FTPで書き漏れ・ 置き間違い 一部の ファイルだけ転送し忘れる、 別環境の ファイルを 上書きする。 手作業では 防ぎようが なく、 しかも 発覚が 遅れがちです - 本番でしか
気づかない — ローカルではエラー 動いた コードが、 依存パッケージや PHPバージョンの 違いで 本番だけ 壊れる。 テストの 自動実行が ないと、 確認は 「反映後に 画面を 見る」だけに なります - 「戻せない」問題 — 手作業デプロイは
反映前の 状態が 残っていない ことが 多く、 不具合時の 切り戻しに 時間が かかります - 属人化 — 手順が
特定の 人の 頭の 中に しかなく、 その 人が 不在だと 緊急修正すら 出せない。 デプロイが 怖い ものになり、 リリース頻度が 下がっていきます
CI/CDを入れると何が変わるか
| 観点 | 手動 | CI/CD導入後 |
|---|---|---|
| 作業ミス | 転送漏れ・上 | 毎回 |
| 品質確認 | 反映後に | 反映前に |
| 切り戻し | 手作業で | 直前の |
| 属人性 | 特定の | 手順が |
| リリース頻度 | 怖いので | 小さな |
特に
GitHub Actionsで小さく始める3段階
CI/CDツールには
- 第1段階：テストの
自動実行 — まずは（CI） pushや プルリクエストの たびに テストと Lint （構文チェック）を 自動実行するだけの ワークフローを 作ります。 テストが まだ 無い プロジェクトなら、 「ビルドが 通るか」 「構文エラーが ないか」の 確認だけでも 十分な 第一歩です。 デプロイには 一切触らないので、 既存の 運用を 壊すリスクが ありません - 第2段階：ビルドの
自動化 — CSS/JSのビルドや 依存パッケージの インストールなど、 「デプロイ前に やっている 手作業」を ワークフローに 移します。 「ビルド成果物を 作る ところまで 自動、 配置は 手動」と いう 中間状態を 挟む ことで、 安全に 移行できます - 第3段階：デプロイの
自動化 — mainブランチへの（CD） マージを きっかけに、 サーバーへの 配置まで 自動化します。 最初は 本番ではなく ステージング環境への 自動デプロイから 始め、 本番は 「手動で ボタンを 押したら 実行される」承認付きに しておくと 心理的な 抵抗も 小さくなります
各段階は
導入時につまずきやすいポイント
- 秘密情報の
ベタ — サーバーの書き パスワードや APIキーを ワークフローファイルに 直接書いてはいけません。 GitHub Actionsの Secrets機能に 登録して 参照します - 本番と
検証環境の — CIでは差分 通るのに 本番で 動かない 場合、 環境差が 原因です。 PHPや Node.jsの バージョンを ワークフロー内で 本番に 合わせて 固定します - テストが
ない —コードベース 「テストを 書いてから CI/CD」と 考えると 永遠に 始まりません。 順序は 逆で、 まず 構文チェックだけの CIを 敷き、 以後の 変更 分から テストを 足していく ほうが 現実的です - 共有サーバーへの
デプロイ — レンタルサーバーなどSSHが 制限された 環境では 選択肢が 限られますが、 FTPSや rsyncでの 自動転送に 対応した Actionを 使えば 自動化自体は 可能です
導入効果はどう測るか
CI/CDの
- デプロイ頻度 — 月1回の
まとめリリースが 週次・日次に できているか。 頻度が 上がる ほど 1回あたりの 変更が 小さくなり、 不具合の 切り分けも 楽に なります - デプロイ作業に
かかる — 手順書を時間 見ながら 30分〜1時間かけていた 作業が、 マージ後の 数分 待ちに 変わります。 担当者の 拘束時間と して 金額換算できます - 本番障害からの
復旧時間 — 切り戻しが「再デプロイ1回」に なる ことで、 障害対応の 時間が 大きく 縮みます
小規模チームでも、
まとめ｜「デプロイが怖くない状態」を最初のゴールに
CI/CD導入の