私のチームも同様の問題に直面しました。gitを使用して、プラグインや作成するテーマなどの独自のカスタムコードをバージョン管理します。Composerを使用して、作成しなかったプラグインなどの依存関係を管理します。composer.jsonファイルとcomposer.lockファイルをgitにチェックインして、全員の同期を保ちます。各開発者はgit masterブランチをプルcomposer update
し、プレイペンで頻繁に実行することで、全員が最新の状態を保つことが期待されています。
データベースでは、開発者は主に構成に関心があり、WP-CLIを使用して構成の同期を保つことがよくあります。たとえば、WP-CLIコマンドを実行してホストごとにプラグインを有効または無効にするシェルスクリプトがあります。たとえば、一部のプラグインはコンテンツステージングホストでのみ使用されるため、スクリプトはどのホストでも実行でき、そのホストで適切なセットのみを有効にします。スクリプトに時間がかかりすぎる構成は、必要に応じて文書化して手動で複製するだけです。
また、コンテンツステージングサーバーからQAまたはdevホストにデータベースを完全に複製するperlスクリプトもあります。開発者は、現在のすべてのコンテンツが必要な場合、定期的にこれを使用できますが、通常はコードと構成を保持するよりも重要ではありません。スクリプトは次のタスクを実行します。
- コンテンツステージングサーバーのデータベースのmySQLダンプ、テーブル名の変更、ターゲットサーバーのデータベースへのロード
- wp-cliを使用して、データベース内のステージングサーバーへの参照を変更し、ターゲットサーバーを参照する
- ターゲットサーバーのアップロードディレクトリをコンテンツステージングサーバーのアップロードと同期する
データベースを実際にバージョン管理するための有望なソリューションがいくつかありますが、それらはすぐに登場します。VersionPressとMergebotは私が知っている2人であり、他にもあるかもしれません。
私はブログでgitとComposerで動作するようにWordPressを設定する方法の技術的な詳細を書きました。gitで維持するコードとWordPressコアを明確に分離するには、WordPressコアを独自のディレクトリで実行する必要がありました。WordPress自体を依存関係として扱い、Composerで管理します。