システムとITのはざまで

自分のITノウハウを誰かのために役立てたくて

WordPress お手軽開発環境の維持

本番環境とのsyncする?

syncというのは、つまり本番環境をそのものをシンクロナイズさせるという意味です。開発環境として温めているものがなければ、定期的に本番環境のクローン環境として開発環境を維持しておくのは、何かと便利です。

以下、簡単ですが概略を記載しておきます。ただし、適宜行間を読んでいただく必要があります。ということで、行間を理解できるレベルであれば、これから記載することは新鮮な内容では... ない。

結局は自分メモになり下がってしまいます。

行間を理解できない方は、これを機会に行間を考えてみてください。理解できたときには、もはや立派なエンジニアです。

概略

  • 本番環境DB(Database)のdump取得
  • 本番環境WP(以下、WordPress)のファイル取得
  • DBの必要箇所を修正

難しくないです。本番環境のBackup & Restore訓練にもなります。円滑にRestoreできるありがた味は貴重です。

なお、くれぐれも自己責任でお願いします。

DBのBackupとResotre

本番環境とテスト環境のDBは、同じ構造になっていること、予めご了承ください。仮に違うデーターベース名・違うテーブル接頭語などありましたら、各々微調整ください。(これが「行間」という意味)

MySQLのコマンドを叩きます。

本番環境で取得。

> mysqldump -u (ユーザー名) -p (データーベース名) > xx.sql

FTPで開発環境へ移して、上書きします。

> mysql -u (ユーザー名) -p (データーベース名) < xx.sql

ファイルの取得

さほど珍しくないです。

本番環境で取得。

$ tar zcvf /var/tmp/xx.tgz (WPインストールDir)/wp-content/

FTPで開発環境へ移して、上書きします。上書き前は適宜バックアップなり、退避させてください。なお、wp-config.php は上書きしないよう注意してください(この辺も行間)。

$ tar ztvf xx.tgz
$ tar zxvf xx.tgz

もちろん、tarにおけるパス名も適宜決めてください。

DBの微調整

上記でも触れましたが、テーブル接頭語などの差異は適宜対応。内容まとめ自動化するか、予めこの種の作業を想定し、同じように環境を構築しておくかです。

mysql> select * from wp_options where option_name ..(略).. ;
+-----------+-------------+-------------------------+----------+
| option_id | option_name | option_value            | autoload |
+-----------+-------------+-------------------------+----------+
|         1 | siteurl     | http://(開発環境のもの)  | yes      |
|         2 | home        | http://(開発環境のもの)  | yes      |
+-----------+-------------+-------------------------+----------+

たかだか数ステップなので、私も自動化したいのですが、久しくシェルプログラミングをしていないので、そう簡単に着手できずにおります。それに、サイトが大きくなって行けば、差分バックアップとか考える必要性もありますね。まあ、少しづつ前進です。

上へ戻る