独立站DevOps：CI/CDパイプライン、自動テスト、デプロイのロールバックと環境管理

独立站DevOps：CI/CDパイプライン、自動テスト、デプロイのロールバックと環境管理

一、独立站にパイプラインが必要な理由、なぜ「SSHで直接修正」ではだめなのか

独立站でよくあるデプロイ方法は3つあります。FTPでファイルをドラッグ、手動SSHでgitをプル、宝塔パネルで再起動をクリック。この3つは月間アクセスが5000未満ならどれも使えますが、コードとデータベースとサードパーティプラグインを同時に変更し始めると、事故率は指数関数的に上がります。CI/CDの価値はデプロイを速くすることではなく、毎回の変更を再現可能・追跡可能・ロールバック可能にすることです。

判断基準が1つあります。あなたが休暇中に、チームのほかの誰かが安全にデプロイできるかどうか。できないなら、デプロイフローはまだ自動化されていません。B2B独立站はコンテンツ更新の頻度は高くありませんが、フォーム、決済、SEO構造化データに関わる変更が本番でエラーになると、問い合わせに直結します。パフォーマンス側の連動問題はCore Web Vitalsの最適化ペースを参照してください。

二、パイプラインの5段ゲートをどう設計するか

最初から「コミット即リリース」を目指さないでください。独立站のパイプラインは5段に分け、各段で失敗したら即ブロックするのがおすすめです。ビルド、単体テスト、ステージングのスモークテスト、カナリア、全量。ビルド段階では依存バージョンを固定し、イミュータブルなイメージを生成します。単体テスト段階ではユニットテストとコードの静的チェックを実行します。ステージング段階では本番と同構成のstaging環境でE2Eスモークテストを実行します。カナリア段階ではまず5%のトラフィックに切り替えて15分観察します。指標が正常だと確認できたら100%に展開します。

所要時間の上限は厳守する。ビルド5分以内、単体テスト3分以内、ステージング10分以内、カナリア観察15分、合計35分以内。これを超えると開発者はパイプラインを飛ばして手動デプロイに走り、自動化が形骸化する。CDNキャッシュと静的アセットの連携はこちらCDNグローバル高速化。

三、自動テスト：自社サイトではどんなケースを書くべきか

小規模チームは両極端に走りがちだ。テストを一切書かず手動に頼るか、最初からカバレッジ90%を目指すか。自社サイトの現実は、業務ロジックは複雑ではないが、フォーム、SEO、多言語の3つは一度壊れると影響が直撃する。テストは3層に分け、費用対効果の順に並べるのがよい。

第1層は単体テストで、ユーティリティ関数、価格計算、フォームバリデーションをカバーする。目標カバレッジは70%で十分、100%は目指さない。第2層はE2Eスモークテストで、トップページの表示、商品一覧から詳細への遷移、問い合わせフォームの送信成功という3本の主要経路だけを守る。第3層はリグレッションテストで、リリース前にステージング環境で10の主要ページを手動で一通り確認する。構造化データとSchemaの検証はこちらを参照構造化データSchema。

四、デプロイとロールバック：イメージのロールバックとデータのロールバックは別物

ロールバックで最も多い事故は、コードは戻したのにデータベーススキーマが戻っておらず、新バージョンのコードが旧テーブル構造に接続できないというものだ。正しいやり方は、コードとデータベースの変更を2本の独立したパイプラインに分けること。コード変更はブルーグリーンまたはローリングリリースでいつでも切戻し可能にし、データベース変更は前方互換を必須とし、まず拡張-縮小戦略を使う。新しいカラムを追加して旧カラムはそのままにし、コードの切替が完了してからデータを移行し、最後に旧カラムを削除する。

実行可能な判断基準を一つ。データベース構造に関わる変更は、本番反映の前に必ずローカルで本番データのマスキング済みコピーを使い「アップグレード→稼働→ロールバック→再アップグレード」の一連の演習を完走させる。通らなければ本番反映はしない。バックアップとリストア演習の詳しい手順はこちらサイトのバックアップと復元演習。

5. 環境管理、3環境で足りるか

自社サイト運用で最小構成の環境は3つ。devはローカル開発用、stagingはテストとリリース前確認用、prodは実ユーザー用。stagingはprodと同じ構成にする。PHPやNodeのバージョン、データベースのバージョン、拡張機能、CDNルールまで揃える。よくある落とし穴はstagingがSQLiteでprodがMySQLのケース。本番反映後に日付関数の挙動が違うと気づく。

設定の分離は必須。データベースのパスワード、外部APIキー、決済キーはすべて環境変数か設定センター経由にし、コードリポジトリには入れない。簡単な確認方法は、リポジトリをGitHubに公開しても実際のキーが一切漏れなければ合格。多言語サイトでは環境差に翻訳キャッシュの問題も重なる。詳しくはこちら多言語コンテンツ公開フロー。

FAQ よくある質問

最後に

独立系サイトのDevOps成熟度は、インターネット大手と比較する必要はありません。2人の小さなチームでも、GitHub ActionsとDockerイメージとブルーグリーンスクリプトがあれば、デプロイを「深夜3時に手動でファイルをドラッグ」から「出社してボタンを1回押す」に変えられます。事故率を決めるのはツールチェーンの新しさではなく、環境管理、データベースのロールバック、カナリア観察の3つをパイプラインに組み込んでいるかどうかです。

導入は3ステップで進めます。1週目は既存の手動デプロイをスクリプト化し、コマンド1つでデプロイできるようにします。2週目は単体テストとE2Eスモークテストのゲートを追加します。3週目はブルーグリーンリリースとワンクリックロールバックを実現します。3ステップを終えると、デプロイ頻度は週1回から毎日複数回に上がり、事故の平均復旧時間は10分以内に収まります。サイト監視アラートの整備についてはこちらをご覧くださいサイト監視とアラート。

覚えておきたい一言。CI/CDのゴールは「デプロイが速い」ことではなく、「事故が起きても安心して眠れる」ことです。ロールバックが3分以内でできるからこそ、チームは毎日リリースできるのです。