WordPressとGitのワークフロー

私はこの質問が何千回も聞かれたことを知っていますが、WordPressで作業するときにGitを最大限に活用する方法を実際に試しています。

私はウェブを精査し、数十の記事を読みましたが、それらはすべて簡単にトピックをカバーしているようです。最近読んだ中で最も有名なものをいくつか紹介します。

-WordPressを制御するバージョン

-Gitを使用したWordPressテーマの展開の管理

-FTPの代わりにgitを使用してカスタムWordPressテーマを管理します

現在、私のワークフローは次のようになっています。

• WordPressをローカルにインストールする
• テーマを開発する
• ローカルサーバーからWordPressデータベースをエクスポートする
• WordPressデータベースをリモートサーバーにインポートする
• FTP経由でWordPressファイルとテーマをアップロードする
• クライアントが変更を加える
• FTP経由でWordPressファイルとテーマをダウンロードし、リモートサーバーからWordPressデータベースをエクスポートする
• ファイルをローカルで置き換える
• 開発の変更を行う
• FTP経由での再アップロード、リモートサーバーへのデータベースのエクスポートとインポート

Gitはこのプロセスを合理化できることを理解しています。これを行う最良の方法は、追跡する必要のない特定のディレクトリを無視する.gitignoreファイルを作成することと、ローカルおよびリモートの両方のwp-config.phpファイルを作成することです。

しかし、データベースをどのように処理しますか？クライアントは通常、変更を行います（投稿/ページ/プラグイン）。リモートデータベースからエクスポートし、ローカルサーバーにインポートする必要がありますか？

誰かがここで私に最適なワークフローを提案できますか？そして、手順を説明します。

また、GitHubとは異なり、Bitbucketのプライベートリポジトリは無料であるため、おそらくBitbucketを使用したいと思います。

任意の助けをいただければ幸いです。

前もって感謝します！

私はWP Migrate DB Proの開発者の一人で、@ Ennuiの質問に答えたいと思います。

「実行するdb url置換スクリプトがシリアル化された文字列を考慮するかどうかを知っていますか？」

はい、シリアル化されたデータを処理します。実際、それが2009年にプラグインの無料版を開発した主な理由です。:)

残念ながら、私は41の評判しか持っていないので、@ Ennuiのコメントに返信できませんでした。そのために残念。

私はこれを「建設的ではない」として締めくくることに投票している。それは答えではなく議論や意見を求めるようなものだからだ。しかし...

それは私の仕事の流れのようには見えず、私のアプローチ（および答え）をこれまでのほとんどの答えとは異なるものにします。

1. WordPressをローカルにインストールする
   1. これは、最新の安定版リリースを含むローカルのベアGitリポジトリから複製されます。
   2. また、ほとんど常にインストールするいくつかのプラグインの最新リリースのローカルコピーを保持しています。
2. テーマと必要なプラグインを作成します
3. パブリックステージングサーバーにアップロードする
   1. クライアントにはアクセス権が与えられますが、コードを変更することはできず、データベースの編集内容が本番サイトに転送されないことを伝えました。
   2. これは、開発サーバーにコードをダウンロードして戻す理由がないことを意味します。
   3. そして、ローカルデータベースを再同期する理由はありません
4. スタッフとクライアントのフィードバックに基づいて、ローカルサイトを変更します。
5. 変更をアップロード
6. 必要に応じて繰り返します（ただし、抵抗を増やします）。）
7. コンテンツを提供する場合は、常にそうとは限りませんが、（クライアントではなく）ステージングサーバー上のデータベースをクリーンアップし、コンテンツをアップロードします。
8. ローカルコードを運用サイトにアップロードして展開します。
9. コンテンツを作成した場合、コンテンツはバニラエクスポートツールを介してステージングサイトからエクスポートされ、実稼働サイトにインポートされます。
   1. これは私がデータベースを移動する必要がある唯一の時間であり、かなり標準的なツールで行われます。必要に応じて、Velvet Blues Update URLを使用してデータベースをクリーンアップします。
10. デバッグ
11. 終わり

基本的には、サイトを引き渡すまで、クライアントをできる限り自分のものから遠ざけます。

コードは、ローカルからステージングまたは実稼働のいずれかに一方向に移動します。他の方法で移動することはありません。それはあなたのステップのいくつかを排除し、私にいくつかの安心を与えます。クライアントがコードをいじくり回したことを責められたくはありませんし、ハッキングされたファイルをインポートしたくはありません。これはゼロではない可能性です。

また、データベースは1回しか移動しないため、問題が大幅に軽減されます。だから、データベースを移動する必要性を減らすか削除することで、「データベースの移動」問題を管理していると思います。また、発生する可能性のあるデータベース破損の問題を減らし、ハックをインポートする可能性を減らします。

確かに、パーマリンク、メニューなどの実稼働サイトを構成する必要がありますが、実稼働サイトでの作業を余儀なくされるため、一種のデバッグと見なします。実稼働サイトで物事が本来どおりに機能することを確認するのに役立ちます。

https://github.com/nathanielks/Wordpress-Capistrano-Deploy

私は（まだ）自分でこれを試していませんが、すべてを展開すると主張しています-DBが含まれています。

それに伴うチュートリアルもあります。チュートリアルパート1 | パート2

岩盤スタックを見てください。コンポーザーを使用してWordpressのバージョンとサードパーティのプラグインを管理し、展開用のcapistranoと、開発用のローカル仮想サーバーを含むサーバーのセットアップ用のvagrant / ansibleも含まれています。

私は最近、これに関して多くのテストを行いましたが、ここで私が使用するワークフローは、あなたが求めていることとほぼ同じです：

• 私はwp-cliを使用してwordpressコアを管理し、wordpressを更新します。
• http://wpackagist.orgとともにcomposerを使用して、プラグインとテーマの依存関係を管理します。
• gitを使用し、コアwpファイルを.gitignoreに配置します。そのため、主にwp-config.phpと子テーマファイルはgitにあります。

私はdb移行ツールに精通していませんが、このワークフローへの素晴らしい追加になるでしょう。

ワークフローの詳細はこちらhttp://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

データベースの「クローニング」に関しては、WP Migrate DB Proを使用しています：http : //deliciousbrains.com/wp-migrate-db-pro/

これは有料のサービスですが、費用はそれほどかかりません。また、開発者からライブサーバーへ、またはその逆にデータベースを簡単にプルまたはプッシュできます。それは途中で変更する必要があるURLおよびその他すべてを変更します。