先の投稿でも書いたとおり、6月7〜8日開催されたWordCamp Kansai 2014に参加し、公募枠で登壇してきました。

セッションを聞いてくださった皆様、ありがとうございました。

セッションのタイトルは「WordPressサイト制作におけるデプロイメントを考える〜Gitとデプロイメントサービスの活用〜」です。概要はというと、WordCamp Kansaiのサイトからの引用になりますが：

現在WordPressサイトの構築や更新には、FTPもしくはSFTPソフトを利用したデプロイメントが主流です。サイト全体の引っ越しであれば、あるいはrsyncやscpといったコマンドを使う場合もあるでしょう。しかし手動で行う作業や、不慣れなコマンドを使うことにより、ミスしたり、時間が掛かったりしませんか？

一方で、最近は開発にGitを用いたVCを実践している、あるいは検討、勉強しているという方も少しずつ増えてきている反面、実務でわざわざ使う利点をイマイチ見いだせていない…という方もいるはず。

そこでGitとデプロイツール（サービス）を組み合わせたテーマ、プラグイン、サイト全体の、より効率的かつスピーディーなデプロイとその自動化を提案します。また、WordPressサイトにこのワークフローを導入する際の注意点も考えます。

まだまだ、個人と職場両方の場で模索しながらこのワークフローを試しています。実績に基づく「これをやっておけばよい」という正解をシェアできるものではありませんが、同様に模索している方や興味ある方と現在のノウハウをシェアしあい、インスパイアしあえるきっかけになればと思います。

副題に「デプロイメントサービス」とありますが、ツールも紹介しています。アウトラインはこんな感じ。

  • What is Deploy/Deployment?
  • Today’s Agenda
  • Where should I git init?
  • Code Deployment
  • Contents Deployment
  • More Advanced Deployment Tools
  • Towards a Full Stuck WordPress Development Tools
  • Managed WordPress Hosting
  • Message

このうち、「Contents Deployment」と「Managed WordPress Hosting」は時間が足りなく飛ばしましたが、Slideshareにアップしたスライド（下記）に入っています。

伝えたかったこと

ツールやサービスなど難しいことを駆け足で話しましたが、もっとも伝えたかったことは3つの「Message」です。

  1. 何はともあれGit。
  2. よりストレスフリーなデプロイメントを目指してデプロイメントのツールやサービスを使ってみよう（車輪の再発明はしない）。
  3. Full Stack方向を意識しつつ、情報のアンテナを張り、手を動かしてみる。

特に3つめなのですが：

20140607_wpkansai-slide_ver6-Final-128

紹介したデプロイメントツールとサービスも、手を動かして使ってみないと理解しづらいと思いますし、実戦投入できるかどうか？するのであればどんなプロジェクトでできそうなのか？判断が付けづらいかと思います。しかし、WordBench Osakaを始め、関西のコミュニティではGitや翻訳など、手を動かして何かproductiveなことをしよう！と挑戦されている印象があります。Gitで一歩、いや、数歩進み始めた方が「次の挑戦に検討してみる題材の1つになれるのでは？」とは今回応募した理由の1つです。皆さんどうでしょうか？

スライドのフォローアップ

登壇後に頂いた質問では、飛ばしたContents Deploymentに関わる内容もありましたので、そのあたりを中心に下記に補足しておきます。

Contents Deployment

コンテンツ、つまりDBと/uploads/ディレクトリをローカル、ステージング、プロダクションのサーバー間で簡単にデプロイする方法ですが、選択肢はほとんどありません。更に、サーバー間で同期する方法も多くはありません。

真っ先に考えられるのはrsyncやmysqldump等のコマンドを使ったスクリプトを作成し、サーバーに置いておき、手動またはCronを使って自動で実行する手法です。URLの置換にはシリアライズされた値にも対応する必要がありますが、WordPressのDBのURL置換用のスクリプトが既に存在するのでそれらを使うと簡単です。もう既に何かしらの自動処理を独自で行ってらっしゃる方はおそらくこの方法ですよね？

WP-CLIがインストールされていれば、WP-CLIのwp dbとwp search-replaceを使うのも手でしょう。wp search-replaceはシリアライズされた値にも対応しています。

より簡単に、であればプラグインの出番です。しかしこれも選択所はほとんどなく、WP Migrate DB Proと、RAMPという2つの有料プラグインぐらいしかありません。

WP Migrate DB Proはローカル、ステージング、プロダクション、それぞれのサーバーに構築したWordPress全てにインストールし、ボタン1つでDBを指定のサーバーへ、URLを適切に置換した上でアップしてくれます。Developer以上のライセンスであれば、メディアファイル（/uploads/にアップした画像など）も差分だけ転送してくれるアドオンや、WP-CLIに対応するアドオン（現在beta）も用意されています。公式サイトにはキャプチャ動画がアップされているので興味のある方は見てみてください。

RAMPは、ステージングサーバーのコンテンツをプロダクションサーバーへ差分デプロイする為のプラグインです。使用している人は少ないのか、あまり情報はありません。

Notes

注意点、もしくは要検討するべき点を3つスライドの中で挙げましたが、他にもあります。

WordPressのメンテナンスモード

デプロイ中にサイトへアクセスすると、もちろん、うまく表示されません。デプロイ内容にもよるとは思います。ですので、デプロイ中の処理も考えなければいけません。個人ブログやアクセスが少ない時間があり、差分が発生するファイルも少なければ、アクセスが少ない時間を狙いデプロイする方法がありますね。しかし、サイト全体をGitの管理下に置いているサイトや、アクセス数が多いサイトではWordPressのメンテナンスモードを使いましょう。ベストプラクティスとして知っておいて損はしない機能でもあります。詳しくは下記のサイトを参照してください。

Managed WordPress Hosting

スライドの中では海外の Managed WordPress Hostingサービスしか紹介していませんが、日本のホスティングサービスでも同様のステージング＋デプロイ機能を備えているサービスがあることを後で知りました。

WordCamp Kansaiのスポンサーでもあるアイティーエー株式会社さんが運営しているWordPress専用レンタルサーバーでは、「2つの環境をセットで用意」と「2つの環境の同期」の2つ機能を実装してらっしゃるそうです。気になる方は試してみてはどうでしょうか？

VersionPress（2014-06-22 22:46追記）

コードをGitでバージョン管理するのであれば、コンテンツ（メディアファイル＋DB）も何とか併せてバージョン管理できないもんだろうか？とやはり皆考えるようで、先日VersionPressというプラグインの開発が発表されていましたので記事にしておきました。