進行中のサイトで作業する複数の開発者/編集者


28

バックグラウンド

私は最初のかなり大きなWordPressサイトを構築する最終段階に近づいていますが、今は多少の摩擦に直面しています。ほとんどの場合、サイトはローカルマシンで開発されたので、レビューのために変更をステージングサーバーにプッシュします(詳細については、この質問を参照してください)。私がコンテンツを編集しているだけのとき、私が最終的に解決したソリューションは非常にうまく機能しましたが、今では追加する機能がありながら他の人がコンテンツを編集しています。アイデアは、機能とコンテンツが一致して一緒になった場合、より迅速に物事を成し遂げることができるということでした...しかし、今は確信が持てません。

現在、ステージングサーバーのデータベースには、ローカルマシンのデータベースとは異なるコンテンツがあります。ローカルマシンに最終的なボディコピーは必要ないので、それ自体は問題ありませんが、データベースに影響する開発をさらに行う必要があります(独自のテーブルを必要とするプラグインをさらにインストール/作成します)。

私の質問は:

複数のユーザーがWordPressインストールで作業できるように、データベースのマージを自動化する簡単な方法はありますか?もちろん、ローカルマシンで変更したことわかっているテーブルをエクスポートしてステージングサーバーにプッシュすることもできますが、ステージングサーバーに停止したいものがある可能性もあります。両方のDBのSQL出力を取得し、それらを比較することができました...しかし、それは退屈でハックのようです。これは他の人が解決した問題なのだろうかと思っています。この種のことを処理するためにコミュニティが受け入れた方法がある場合。

ありがとう!


別のサイトを閉じるか、別のサイトに移動するかどうかの投票(1月:良いサイトについて何か考えはありますか?スーパーユーザーかもしれません)。Drupal、Joomla、またはPHP + MySQL駆動型サイトで同じ問題が発生するため、これはWordPress固有のものではありません。
ジョンPブロッホ

そうは言っても、ローカルのサーバーではなくリモートのステージングサーバーを使用することをお勧めします。
ジョンPブロッホ

@John P Bloch:Drupalでは、Drushのようなものがこの状況で大いに役立ちます。私は個人的にDjangoに慣れており、この種の問題はフィクスチャによって軽減されています。また、現在、ローカルとリモートの2つのステージングサーバーがあります。問題は、リモートマシンで作業を行いますが、他の人が見えるようにサーバーにプッシュする必要があるということです。最終的なサーバーは、すべてが揃ったときにセットアップされるものです。
ギャビンアンデレッグ

2
@John P Bloch-これが良い質問としてここで理にかなっている理由があると思う。現時点ではそれに答える時間はありませんが、できれば他の人が答えることを願っています。
MikeSchinkel

1
@ギャビン:すみません、あなたの質問を誤って解釈しました。はい、運用サーバー上のすべてを上書きすると思います。:/
ザック

回答:


16

私は1年以上前にこの質問をしましたが、その間にチームにさらに多くの人を追加し、WordPressで非常に多くのサイトを開発しました。他の人に役立つかもしれない場合に備えて、私たちのプロセスを見ていきたいと思いました。

Gitのすべて

これは私が質問をしているときでさえ行っていたことでしたが、この点を指摘するのは良いことです。Gitを使用することで生産性が向上しただけでなく、集団でのロバを数回節約できました。

サイトの構造的な大規模な改修を行い、クライアントから改修の承認を得て、改修されていないバージョンのマイナーな更新を行う必要がありましたか?Gitがそれを実現しました。この設定を説明するには少し時間がかかりますが、基本は新しいブランチを作成し、そのブランチをサーバーにプルし、サブドメインをそのブランチにアタッチすることです。

また、Gitによって保存されました。もちろん、変更をロールバックできますが、これは素晴らしいことですが、ファイルの古いバージョンを戻すこともできます。これは、クライアントが「サイトのこの部分が約1年前にどのように機能したか覚えていますか?それを戻すことができますか?」前。

これらの点に加えて、必要なファイルなしで立ち往生することもありません。どのマシンからでも最新バージョンのサイトをいつでもプルダウンして、変更を開始できます。

Gitを使用して展開する

Media TempleでWordPressホスティングを行っており、本当に気に入っています。彼らは最も安いプロバイダーではありませんが、彼らのサービスは優れており、彼らのサーバーは本当にうまくセットアップされています。また、デフォルトでGitも提供します。つまり、サーバーをGitリポジトリとして設定し、SFTPを使用する代わりにその方法で変更をプルできます。また、サーバーで作業を行うことで上書きされる危険性がないことも意味します(これらの変更は単にマージしてプッシュバックできるため)。

BitBucketをGitホストとして使用しているため、ここでは少し余分な作業が必要です。まず、.ssh / configファイルを使用ssh sitenameして、サーバーへのログインなどを入力できるようにします(パスワードなしのSSHも使用しているため、非常に簡単です)。また、必ずsshパスフレーズを使用するようにします(Mac OS Xでは、パスフレーズをKeychain.appに保存できるため、これが非常に簡単になります)。最後に、ForwardAgent行を、プルしたいホストの.ssh / configエントリに追加します。これは、各サーバーの公開キーではなく、BitBucketで各人のSSH公開キーのみが必要であることを意味します。また、.gitディレクトリをパブリックHTMLディレクトリの1つ上のディレクトリに保持するようにします。

自動化されたデータベースダンプ

サーバーが運用モードになると、念のため、データベース自動的にバックアップします

誰もが独自のwp-configを持っています

独自のローカルデータベースのユーザー名とパスワードがあり、異なる名前とサービスメカニズムを使用できるため、それぞれ独自のwp-configファイルを保持しています。これらはそれぞれGitのような名前でGitに保存され、wp-config-gavin.phpその構成を使用する場合、シンボリックリンクしますwp-config.php.gitignoreを使用するGitでは無視されます)。

これによりsiteurlwp_optionsデータベーステーブルのオプションを次のようにオーバーライドすることもできます。

define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');

これにより、WordPressはサーバーの場所をデータベースで確認できなくなり、ローカルインストールとサーバーインストールの場所に奇妙な違いがないことを意味します。

wp-config.phpファイルに関する最後の注意点:必ず公開HTMLディレクトリの上保存し、Webユーザーのアクセス許可を読み取り専用にします。これにより、WordPressの保護に大きな違いが生じます。

データベースの問題

最後に、問題の肉。

私が受け入れなければならなかったのは、WordPressを使用するとき、データベースの変更を「マージ」する良い方法がないということです。代わりに、これを解決するための行動ルールを開発する必要がありました。ルールはかなり単純で、これまでのところ私たちに役立っています。

開発中、サイトを「所有」する人が一人います。通常、その人がセットアップを行います(ホスティングパッケージを取得し、Basecampプロジェクトを開始し、デザインをスライスします)。その人が妥当な位置に来たら、WordPressインストール用のデータベースをダンプしてGitに入れます。その時点から、開発を行うすべての人がそのデータベースダンプを使用し、所有者のみがデータベースに変更を加えます。

サイトの構築が少し進むと、サイトはサーバーに配置されます。その時点から、サーバーのデータベースは標準になります。全員(所有者を含む)は、サーバー上ですべてのデータベースの変更を行い、ローカルの開発とテストのために変更をプルダウンする必要があります。

このプロセスは完璧ではありません。開発中に誰かがWordPressバックエンドをローカルで変更する必要があり、本番環境でそれらの変更を再度行う必要がある可能性があります。ただし、そのようなことはまれであることがわかり、このプロセスは非常にうまく機能します。


1

私はそのようなインストールに取り組み、持っています 以前にこのような質問に答えました。以下は、この種の作業に適したセットアップです。既存のデータベースを置き換えるのではなくデータベースをマージするため、MySQLダンプを実行するときに--add-drop-tableフラグを使用しないように注意してください。


  • ステップ1.開発データベースのMysqldump
  • ステップ2. development.domain.comのすべてのインスタンスをproduction.domain.comに置き換えます^^
  • ステップ3. MySQLにログインし、SOURCEコマンドを実行してデータをインポートします。 source /path/to/file

^^古いドメインのすべてのインスタンスを新しいものに置き換える方法:(1)以下のスクリプトをコピーします。(2)chmod +xそれ。(3)実行します。

使用法: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g

2
注意してください:sedは、以前にシリアル化されたmysqlダンプ内でエンコードされたデータを処理できません。
hakre

前にあなたが答えた質問は私のものでした。実際、ここで別の質問をしているように感じます。作業中のDB全体をダンプするのは素晴らしいことですが、上記の状況でそれを行うと、他の人の変更を上書きするか、自分の変更を上書きします。複数の人がWordPressインスタンスで作業するので、変更を組み合わせたいと考えています。
ギャビンアンデレッグ

1

私は今、この同じ問題のさまざまな解決策を試しています。それは間違いなくトリッキーなものです。

私の現在の解決策は、--skip-extended-insertフラグを使用してローカルmysqlダンプを実行することです。このフラグにより​​、データベースのすべての行に対してレコードの挿入ステートメントが生成され、ダンプが少しマージしやすくなると思います。私はこの記事http://www.viget.com/extend/backup-your-database-in-git/からそのトリックを取り上げました。

次に、Gitとサイトのソースファイルを使用して、結果の.sqlデータダンプファイルをソース管理します。別の開発者がコードの変更をプルダウンすると、.sqlファイルが一緒に追加されます。次に、このファイルをローカルバージョンのデータベースにインポートします。両方ともMAMPを使用して、両方のマシンでそれぞれのローカルデータベースを同じ方法でセットアップしているため、検索や置換を行う必要はありません。

マージの問題があったため、データベースの変更の原因となるものすべてに対して「テイクターン」アプローチを採用しようとしています。データベースを変更するWordpressで何かを行う前に、彼が最新のダンプでチェックインし、それをプルしてインポートしていることを確認し、私のチェックインとチェックインが完了するまでDBを変更しないように依頼します。これは明らかに理想的ではなく、より良い解決策を探していますが、それは出発点です。また、DBのバージョン管理も可能になります。

サーバー上で共有devデータベースをセットアップして、SSHトンネリングを介して同じDBにWebサイトのローカルコピーの両方を接続してみます。ただし、この方法では、プラグインをインストールするたびに問題が発生します。基本的に、PHPファイルとMySQL DBは同期していません。

他の人がこの問題にどのように対処しているか聞いてみたいです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.