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

ローカル開発環境が本番サーバーと一致しない場合、実質的にコーディングは暗闇で行っているようなものです。

すべてが機能していると思っているかもしれません。おそらく機能しているでしょう—あなたのマシン上では。しかし、重要なのはそこではありません。

本番環境とローカル開発環境を同期させる信頼性の高いプロセスを持つことは、単なる「あれば嬉しい」ものではありません。それは、デプロイするたびに指をクロスさせている人たちとプロフェッショナルを分けるものです。

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

主なポイントは次のとおりです：

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

目次

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

環境を同期しなくても、おそらくやっていけるでしょう。多くの人がそうしています。彼らは、時折起こる予期せぬバグ、ローカルでは発生しなかったランダムな本番環境の問題、そしてアップデートをプッシュするたびに感じる不安感に対処しているだけです。

しかし、なぜそんな苦労をする必要があるのでしょうか？

ローカル環境と本番環境を同期させ続けることで、多くの問題が解消されます。正しく行うことで実際に得られるものは次のとおりです。

本番環境に移行する前にエラーを検出する

同期されたローカル環境は、本番サーバーの実際の構成をミラーリングします。PHPのバージョン、データベース構造、プラグインはすべて同じバージョンになります。

これはあなたが思う以上に重要です。

本番環境と一致するローカルセットアップで作業すると、互換性の問題がすぐに表面化します。それらはユーザーの前にではなく、あなたのデスクで検出されます。それは、軽微な不便さと実際の問題との違いです。

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

ダミーデータに対してテストすることは、初期機能を構築する際には問題ありません。しかし、ある時点では、実際にどのように動作するかを見る必要があります。

実際のユーザーコンテンツは複雑です。製品カタログには奇妙なエッジケースがあります。

あなたのローカルサイトは、何が起こっているのかを正確に把握するために、その実際のデータが必要です。

本番環境から同期することで、コードがやり取りする実際の投稿、ユーザー、製品を取得できます。もう推測しているのではなく、現実に照らしてテストしています。

互換性の問題なし

すべての開発者は、少なくとも一度は「でも、私のマシンでは動いたんだ」と言ったことがあります。これはもはやミームのようなものです。

しかし、それはまた、一致しない環境の症状でもあります。ローカルセットアップが本番環境とほぼ同一であれば、この言い訳はなくなります。ローカルで機能すれば、ライブでも機能します。

そのような自信は、あなたの働き方を変えます。デプロイのたびに二度考えなくなります。

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

一人で作業している場合、乱雑なプロセスでも何とかやっていけます。しかし、二人目の開発者が加わると、状況はすぐに複雑になります。

一貫した同期プロセスにより、全員が同じベースラインから開始できます。同じデータベース、同じコンテンツ構造、同じ環境設定でテストを実行します。

それがなければ、3つの異なる「ローカル」バージョンができあがり、どれが本番環境に最も近いのか誰もわからなくなります。それは協力ではなく、混沌です。

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

これは手動で行うこともできます。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 のような URL です。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を使用している場合は、追跡しないものを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開発者ツール
• 開発者が1億5000万製品のオンラインストアを簡単に移行する方法