ローカル開発環境と本番環境を同期する方法

ローカル開発環境と本番サーバーが一致しない場合、あなたは基本的に目隠し状態でコーディングしているようなものです。

すべてがうまくいっていると思うかもしれない。おそらく、あなたのマシン上ではうまくいっているだろう。しかし、重要なのはそこではない。

ローカル開発環境と本番環境を同期する信頼性の高いプロセスは、単なる「あれば便利なもの」ではない。デプロイのたびに祈るような気持ちになる人々と、プロフェッショナルを分ける決定的な要素なのだ。

この記事では、環境を同期させるための実証済みの方法を順を追って説明します。あなたのワークフローに合った方法が見つかるはずです！

以下はその要点である：

• 環境の同期化により互換性の問題を解消し、ユーザーが気づく前にバグを発見できる
• 初心者向けのローカル同期ワークフローにはDuplicatorを、コマンドライン操作にはGitHubとWP-CLIを利用できます
• 常に本番環境からデータベースをダウンロードし、コード変更のみをプッシュして、稼働中のデータが上書きされるのを防ぐ
• WordPressサイトには同期する3つの部分があります：コード（Git）、データベース（WP-CLI）、メディアファイル（rsync）
• 同期を行う前には必ずバックアップを取り、テストにはステージング環境を使用し、適切な.gitignoreファイルを維持してください

目次

ローカル環境と本番環境を同期する理由とは？

環境を同期しなくてもおそらく生き延びられる。そうしている人は大勢いる。ただ、たまに予期せぬバグに遭遇したり、ローカルでは発生しなかったランダムな本番環境の問題に直面したり、更新をプッシュするたびに付きまとう不安と向き合っているだけだ。

でも、なぜそんな目に遭う必要があるのか？

ローカル環境と本番環境を同期させることで、多くの問題が解消されます。正しく行うことで得られる実際のメリットは以下の通りです。

本番環境移行前にエラーを捕捉する

同期されたローカル環境は、本番サーバーの実際の構成を反映します。同じPHPバージョン、データベース構造、および同じバージョンのプラグインを備えています。

これはあなたが思っている以上に重要です。

本番環境と一致するローカル環境で作業すると、互換性の問題は即座に表面化する。ユーザーの前ではなく、自分のデスクで問題を発見できる。これが些細な不便と真の問題の違いだ。

テストのための現実的なサンドボックス

ダミーデータを用いたテストは初期機能の構築には適している。しかし、ある時点で実際の動作を確認する必要が生じる。

実際のユーザーコンテンツは乱雑だ。製品カタログには奇妙な例外ケースが存在する。

現地サイトでは、現状を正確に把握するために実際のデータが必要です。

本番環境から同期することで、コードが実際にやり取りする投稿、ユーザー、商品を入手できます。推測ではなく、現実の環境でテストできるのです。

互換性の問題はありません

開発者なら誰もが一度は「でも俺のマシンでは動いたんだ」と言ったことがある。もはや定番のネタだ。

しかし、これは環境が一致しないことによる症状でもあります。ローカル環境の設定が本番環境と基本的に同一であれば、この言い訳は通用しません。ローカルで動作するなら、本番環境でも動作するはずです。

そうした自信は仕事の仕方を変える。デプロイのたびに疑念を抱くことはなくなる。

チームコラボレーションの向上

一人で作業している時は、プロセスが雑でも何とかなる。しかし、もう一人の開発者が加わると、事態は急速に複雑化する。

一貫した同期プロセスとは、全員が同じ基盤から始めることを意味します。皆が同じデータベースに対してテストを行い、同じコンテンツ構造を使用し、同じ環境設定を実行している状態です。

それがないと、「ローカル」という概念が三つに分裂し、どれが本番環境に最も近いのか誰も確信できなくなる。それはコラボレーションではなく、混乱だ。

ローカル環境と本番環境を同期する方法

手動で行うことも可能です。phpMyAdminでデータベースをエクスポートし、ダウンロードしてローカルにインポートします。その後、SQLファイル内のURLをすべて手動で探し、置換します。次にサーバーにFTP接続し、uploadsフォルダをzip圧縮してダウンロードし、ローカルで解凍します…

それを打ち込むだけで疲れきった。

手動での作業は面倒でリスクが高い。URL置換を1つでも見落とせば、ローカルサイトが本番リソースを指し始める。シリアライズされた配列の更新を正しく忘れると、データベースが破損する。

より良い方法があります。ローカル開発環境と本番環境を同期する方法は次のとおりです：

• Duplicator: 自動URL置換とガイド付きインストーラーを備えた移行プラグイン—初心者や迅速な同期に最適
• GitHub + WP-CLI: Gitによるコード同期、WP-CLIエクスポートによるデータベース同期、rsyncによるメディア同期をコマンドラインで制御—細かな制御を求める開発者に最適

ローカルサイトと本番サイトをDuplicatorで同期する

これは最もわかりやすい方法です。特にターミナルでの操作に慣れていない場合には。

Duplicatorはサイトの完全なスナップショットを作成し、面倒な作業をすべて自動で処理するインストーラーを提供します。手動でのURL置換やデータベース設定の煩わしさについて心配する必要はありません。

本番環境からローカル環境へのプル（一般的なワークフロー）

これが最も頻繁に行う作業です。ライブサイトの現在の状態を取得し、ローカル環境で作業したいのです。

まず、本番サイトにDuplicator Proをインストールし、新しいフルサイトのバックアップを作成します。これは、まさにこの瞬間のサイト全体のスナップショットを撮るようなものと考えてください。

バックアップの作成には、サイトのサイズに応じて数分かかります。完了すると、アーカイブファイル（通常は.dafまたは.zipファイル）とインストーラースクリプト（.phpファイル）の2つのファイルが生成されます。両方ともダウンロードしてください。

次に、ローカル環境へ移動してください。ローカルコピーを配置したい場所に空のディレクトリを作成します。アーカイブファイルとインストーラーファイルの両方を、その空のディレクトリにドロップしてください。

ブラウザを開き、そのディレクトリに移動してください。例：http://localhost/mysite/installer.php。Duplicatorインストーラーウィザードが起動します。

ウィザードがローカルデータベースへの接続手順を案内し、すべてのURL置換を自動的に処理します。

あなたの本番サイトがhttps://mysite.comであり、ローカルサイトがhttp://localhost/mysite であることを認識しています。データベース内のすべての参照を、一切手を加えることなく修正します。

5分後には、本番サイトの完全なローカルコピーが手に入ります。

ローカル環境から本番環境へのデプロイ

このワークフローは逆方向です。ローカルサイトを取り込み、本番環境にデプロイします。

ここには注意が必要です。これは基本的に新規サイトの立ち上げや完全な再設計の場合のみに適用されます。稼働中のサイトにアクティブなユーザーがいる場合、この操作は避けるべきです。ユーザーの最近の投稿、コメント、注文データが上書きされてしまいます。

ローカル環境から本番環境へデプロイする必要がある場合、プロセスは同様ですが逆の手順となります。

まず第一に——これだけは何度でも強調しておきます——他の作業を行う前に、本番サイトを完全にバックアップしてください。

次に、Duplicatorを使用してローカルサイトのバックアップを作成し、ダウンロードします。両方のバックアップファイルをFTP経由で本番サーバーにアップロードするか、アーカイブをインポートページにドラッグ＆ドロップします。

再度：本番環境を完全に置き換えることを確実に望む場合のみ実行してください。予期せぬ変更を容易にロールバックできるようにするため、必ずリカバリポイントを設定してください。

Duplicatorは、たとえサイトが完全に壊れていても、直近のバックアップを復元するリカバリURLを提供します。

ローカルサイトと本番サイトをGitHubとWP-CLIで同期する

コマンドラインに慣れているなら、この方法により制御性が高まり、Gitベースのワークフローに組み込みやすくなります。

WordPressサイトについて重要な点は、それぞれ個別に同期が必要な3つの異なる部分で構成されていることです。

• コード：テーマファイル、プラグイン、およびWordPressのコアファイル。これがGitが扱う対象です。
• データベース：すべてのコンテンツ、設定、構成。Gitはこれには触れません。WP-CLIが必要です。
• メディア: /wp-content/uploads/ フォルダ内のすべてのファイル。Gitにも含まれません。rsync または類似のツールが必要です。

この分離を理解することが鍵となる。Gitだけでは不十分だ。

本番環境からのプル作業のワークフロー

本番サイトをローカル環境に移行する手順を順を追って説明します。

コードに関しては簡単です。テーマとカスタムプラグインがGitリポジトリにある場合、単に以下を実行してください：

git pull origin main

ローカルコードが本番環境と一致するようになりました。

データベースについては、本番サーバーにSSHで接続し、WP-CLIを使用してデータベースをエクスポートします：

wp db export production-backup.sql

その .sql ファイルをローカルマシンにダウンロードしてください。その後、ローカルでインポートします：

wp db import production-backup.sql

しかし、まだ完了していません。データベースにはまだすべての本番環境のURLが残っています。それらをローカル環境のURLに置き換える必要があります：

wp search-replace 'https://mysite.com' 'http://localhost/mysite'

この検索と置換コマンドは、すべてのテーブルとフィールドをくまなく検索し、URLが存在する箇所をすべて更新します。シリアライズされたデータも正しく処理するため、WordPressにとって極めて重要です。

この手順をスキップすると、ローカルサイトは本番環境から画像をロードしようとし、ライブサイトへリダイレクトし、自分がどこにあるのかわからないかのように動作します。

メディアファイルにはrsyncを使用してください。大規模なディレクトリの同期を効率的に行うために設計されています。

rsync -avz user@mysite.com:/path/to/wp-content/uploads/ ./wp-content/uploads/

-avz フラグは「アーカイブモード、詳細出力、転送中の圧縮」を意味します。このコマンドは変更されたファイルのみをダウンロードするため、以降の同期は高速です。

以下の3つの手順（コードの取得、データベースのインポート、メディアの同期）を実行すれば、本番環境の完全なローカルコピーが完成します。

スムーズかつ安全な同期を確保するためのベストプラクティス

世界最高の道具を持っていても、使い方を間違えれば意味がない。

開発者がプルすべき時にプッシュして本番データベースを消去するのを何度も見てきた。「ほんの少しの同期だから」とバックアップを省略した人々が、週末をデータ復旧に費やす姿も何度も目にしてきた。

そんな人間になるな。

これらのベストプラクティスは、円滑な業務フローとキャリアを台無しにするミスとの分かれ目となる。

常に最初にバックアップを取ること

いかなる方向で同期を行う前にも、必ずバックアップを取ってください。一度でもそれを怠ると、必ず何か問題が発生します。

Duplicatorはこれを簡単に行えます——移行とバックアップの両方を兼ね備えたプラグインです。プッシュまたはプル移行の最初のステップは、サイト全体を保護するフルサイトバックアップとなります。

何かあったら、ワンクリック復元ボタンを押してください。

または、両方のバックアップファイルを同じサーバーにアップロードし直してください。インストーラーを実行し、復旧手順に従ってください。

コマンドラインツールを使用している場合は、簡単な wp db export 他のことをする前に。

バックアップ作成に5分かけることで、復旧作業に数日を費やす手間を省けます。

プルダウン、コードをプッシュアップ

標準的なプロフェッショナルなワークフローは以下の通りです：データベースとメディアファイルを本番環境からローカル環境にプルします。コードの変更はGit経由で本番環境へプッシュします。

新しいサイトを立ち上げる場合を除き、ローカルデータベースを本番環境にプッシュすることはほとんどありません。

なぜなら、本番環境には常に変化する実際のデータが存在するためです。ローカルコピーで本番データベースを上書きすると、直近のすべてのアクティビティが失われてしまいます。

ステージング環境を使用する

理想的なワークフローは「ローカル → 本番環境」ではありません。「ローカル → ステージング環境 → 本番環境」です。

ステージング環境とは、本番サイトのコピーであり、実際のサーバー上に存在するものの、一般公開されていない環境です。変更が本番環境に反映される前の最終的なテスト環境となります。

ローカル環境で開発します。その後、本番サーバーの設定と最新の本番データを用いてステージング環境でテストします。ステージング環境ですべてが正常に動作することを確認した後、初めて本番環境にデプロイします。

これにより安全バッファが追加されます。ステージング環境で何かが壊れても、ユーザーには表示されません。問題が深刻化する前に発見し修正できます。

すべてのプロジェクトにステージング環境が必要なわけではありません。特に小規模なサイトでは不要です。しかし、実際のトラフィックがあるサイトやeコマース機能を備えたサイトでは、設定する価値があります。

.gitignore ファイルを使用する

Gitを使用している場合、追跡しないように指示する必要があります。

wp-config.phpファイルには、環境ごとに異なるデータベース認証情報が含まれています。バージョン管理の対象とすべきではありません。

/wp-content/uploads/フォルダには、画像やファイルがギガバイト単位で存在する場合があります。これらもGitの対象外です。rsyncが適しています。

リポジトリのルートディレクトリに .gitignore ファイルを作成し、最低限以下の行を追加してください：

wp-config.php

.htaccess

wp-content/uploads/

*.log

これによりリポジトリをクリーンに保ち、機密情報を誤ってコミットしたり、バイナリファイルでリポジトリを肥大化させたりするのを防ぎます。

よくある質問 (FAQ)

WordPress同期ワークフローを完璧に

手動作業から脱却することは、開発キャリアにおける転換点の一つだ。ファイルをコピーして祈るだけの存在から脱却し、プロセスを確立した人間へと変わるのだ。

繰り返し可能なワークフロー——Duplicatorのようなツールを使用する場合でも、ターミナルでコマンドを実行する場合でも——デプロイの不安を確信へと変える。

将来の自分が感謝するでしょう。本番環境のデータで機能をテストする時、最新のコンテンツを取得する時、ストレスゼロでデプロイする時が来たら。

コマンドラインツールを駆使する手間や手順の抜け落ちを心配する日々に終止符を打ちませんか？Duplicator Proは、サイトの移行とバックアップのための完全かつ信頼性の高いツールキットを提供します。

サイト全体のバックアップを作成し、クラウドストレージに直接送信。面倒な作業はすべてガイド付きインストーラーが処理し、新しい場所に簡単にデプロイできます。ワークフローを今すぐ簡素化するDuplicator Proをチェック！

ここにいる間、私はあなたがこれらの他の厳選されたWordPressリソースを気に入ると思います：

• WordPress CLIの使い方：コマンドラインをマスターしよう
• ライブWordPressサイトをローカルホストに移動する方法（簡単な方法）
• ローカルのWordPressサイトをライブサーバーに移行する方法
• よりスマートに、よりハードに：WordPress開発者向けツール
• 商品点数15万点のオンラインストアを開発者が簡単に移行する方法