私のWordPress開発プロジェクトにも当てはまるように、私はgitワークフローの改善に取り組んでいます。多くの場合、コンテンツ管理システムを開発するときに、制作版で使用されるカスタム投稿タイプと分類法を含む開発サーバー(http://dev.finalsitename.com
など)を作成します。これにより、クライアントは自分のコンテンツをサイトに追加し始めることができます。
彼らがこのタスクに取り組んでいる間、私は通常私のlocalhost環境で使われるであろうカスタムプログラミング/プラグインと同様にルックアンドフィールを構築しています。私が彼らの更新を上書きしないようにするために、私は彼らのデータベースのコピーをプルダウンして私のものに置き換えます。ただし、WP管理者エリアに移動して設定を変更したり、その他の小さな設定を変更したりする必要がある場合があります。
WordPressプロジェクトで作業している開発者が複数いる場合は、それぞれ自分のバージョンのサイトの(タイムスタンプ付き)データベースダンプを作成し、ローカルディレクトリをコミットしてリモートリポジトリにプッシュする前にルートディレクトリに含めます。このアプローチの問題点は、データベースが同期していないことが多く、どちらを使用するかを決定する簡単な方法がないことです。
複数の開発者(およびクライアント/コンテンツ制作者)が同じプロジェクトで作業できるようにしながら、データベースの同期を維持するために他の開発者は何をしていますか?
データベースを完全に同期させる必要がある場合スキーマとデータでは、バックアップに基づいてカスタムバージョン管理システムを開発することができます。
あるいは、データを運用から守りながらそのスキーマを進化させたい場合は、カスタムソリューション(すべてのスキーマ変更を含むバージョン管理されたファイル)、またはmigration
の概念に基づく標準ソリューションを使用することができます。あなたはこのstackoverflowスレッドでたくさんの情報を見つけることができます: dbスキーマ変更を追跡するためのメカニズム 。
これが非常に明白であるように思えば申し訳ありませんが、同じ構造を持つデータベースの同じコピーを持っている必要があるなら、office/central SQLサーバーを持ってそれを使うのは意味がありませんか?実験する必要がある場合はローカルにクローンを作成しますが、それを認証のデファクトスタンダードとして保持し、そのサーバーとそのサーバーのみのバックアップを作成します。
さもなければ私がグループプロジェクトに取り組んでいるとき私達は異なった内容の私達自身のセットアップを持っています。このコードはテーブル構造のアップグレードと移行の面倒を見てくれます、そして私たちはLANを通して私たちのマシンで走っているコードのお互いのローカルインストールにアクセスできるので、私たちがコンテンツを共有する必要はありません。
コンテンツを入力する場合は、テストサーバーで実行してからライブサーバーにエクスポートまたはインポートすることも、現在ライブインスタンスが存在しない場合は本番サーバーに直接移行することもできます。
ライブテストとWIPデータを分離する必要がある場合は、ライブ、テスト、および開発ブランチをリポジトリに使用してください。