12

複数の開発者が別々の場所にいる WordPress プロジェクトに取り組んだことのある人はいますか? 分散した開発チームと自動展開に関するベスト プラクティスはありますか?

私は、プラグイン開発者、テーマ開発者、単純な CSS スタイル調整者など、さまざまなレベルの開発者からなるチームをいくつかの異なる場所に持っています。全員がそれぞれの作業に取り掛かることができるように、優れたシステムをセットアップしたいと考えています。他のユーザーのコードを邪魔することなく、継続的に変更をデプロイします。

システムは現在 WordPress-MU のインストールを実行しており、最終的には 3.0 にアップグレードされます。理想的には、テーマとプラグインをソース管理に保存します。コアの WordPress コードにいくつかの変更が加えられているため、リポジトリにも移動する必要があります。リポジトリを構築し、制御されているがある程度自動化された展開を行うための最良の方法を理解するのに苦労しています。

さまざまな種類のプラグインやテーマがファイル システムまたはデータベースに構成を保存する場合、開発、テスト、ステージング、および運用環境での作業とデプロイをどのように処理しますか? 答えは「WordPress を使用しないでください」かもしれませんが、そうしなければならないと仮定して、あなたの考えを教えてください。

ご協力いただきありがとうございます、

デイブ

4

3 に答える 3

9

これまでにこの問題を解決した方法は次のとおりです。

ソース コード ディレクトリ:

build/ - build files for phing and environment-specific properties files
    build.xml
    src_qa.properties - properties to use the qa server as the source for a deployment
    dst_qa.properties - properties to use the qa server as the destination for a deployment
    etc... for other environments
conf/ - contains environment specific configuration files, each in a subfolder named after the environment
    dev/
        db-config.php - config file for HyperDB - http://codex.wordpress.org/HyperDB
        default - Apache conf that holds ServerAlias configs for multi-site WordPress
        hosts - useful for developers to redirect their browser to various domains in different environments
        htaccess.dist - for WPMU
        httpd.conf - main Apache config file, specific to each environment
        my.cnf - mysql config file
        wp-config.php - main wordpress config file
    qa
        (same as dev/ but with different values in each file)
    staging
        (same as dev/ but with different values in each file)
    prod
        (same as dev/ but with different values in each file)
src/ - wordpress source code
    wp-admin/
    wp-content/
        mu-plugins/
        plugins/
        themes/ 
    wp-includes/
test/ - holds WP test suite and custom tests for plugins, themes, etc...

私は Hudson CI サーバー ( http://hudson-ci.org/ ) を使用して、subversion チェックアウト タスク、phing、phpunit などを使用した自動ビルドと手動ビルドを行っています。展開したいファイルであり、CI サーバーから展開先サーバーに展開されるファイルを rsync します。

または、ステージングから直接本番環境への展開の場合、Hudson rsync は、ステージングから CI サーバーまでファイルを rsync し、その後本番環境にバックアップします。

次の機能のために、ハドソンでビルドジョブをセットアップしました。

core WP code - deploys core WP files and mu-plugins from src to dst
    svn to qa
    svn to staging
    staging to prod
WP plugins/ folder - deploys only the plugins folder 
    svn to qa
    svn to staging
    staging to prod
WP themes/ folder - deploys the entire themes folder
    svn to qa
    svn to staging
    svn to prod
Specific themes - deploys a specific theme (chosen through a drop down during the build process using Hudson's parameterized build feature - http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build)
    svn to qa
    svn to staging
    svn to prod

hudson ジョブには、環境固有の PHP ファイル (wp-config.php、db-config.php など) と、Apache および MySQL 構成ファイルを各サーバーの適切な場所にデプロイする機能もあります。場合によっては、複数の Web サーバーと複数のデータベース サーバーに展開し、ほとんどのビルド構成は、前述の phing ビルド ファイルと .properties ファイルによって処理されます。

将来、開発統合環境ができたら、コードの svn チェックイン時に自動展開を行う可能性があります。

この設定により、組織内のさまざまなスキルセット (主に CSS/HTML と PHP) を持つさまざまな開発者が別々に作業し、多くの不必要な人を巻き込むことなく、コードの変更を適切な環境にすばやく反映させることができます。Hudson を使用すると、さまざまな展開ジョブをロックダウンできるため、適切な人だけがそれらを構成して開始することができます。

これは、私が設定したものの概要です。ご意見をお聞かせください。このセットアップの最大の煩わしさは、キーペア、ユーザー アカウント、およびすべての異なるサーバーで rsync を使用したファイル アクセス許可でした。

デイブ

于 2010-07-14T05:35:31.430 に答える
0

ファイルシステムには GIT を使用しており、非常にうまく機能します。チーム メンバーごとにブランチを作成し、それをプロダクション ブランチにマージできます。問題なくコードを統合したままにすることができます。

データベースについては、prod データベースをダンプし、全員と共有し続けます (GIT リポジトリに送信することもできます。そうすれば、全員が最新のダンプを取得できます)。

于 2010-07-13T18:43:21.680 に答える
-1

ロールアウトは非常に便利であることがわかりました。有料サービスですが、試してみる価値はあります。スクリプティングなし コーディングは一切ありません。サインアップして、そこにあるレシピに従ってください。これで完了です。また、展開を非常にスムーズかつ簡単にする展開前のチェックも行います。

于 2018-05-30T05:52:25.390 に答える