Question

有没有人曾经在不同地点与多个开发人员合作过WordPress项目？是否存在围绕分布式开发团队和自动部署的最佳实践？

我有一个不同程度开发人员的团队，包括插件开发人员，主题开发人员和简单的CSS风格调整器，在几个不同的位置，我想为每个人设置一个良好的系统，以便能够工作他们的分开各个部分并不断干扰其他人的代码。

系统目前正在运行WordPress-MU的安装，最终将升级到3.0。理想情况下，我们会将主题和插件存储在源代码控制中，并且由于对核心WordPress代码进行了一些修改，因此它也必须进入存储库。我无法找到构建存储库的最佳方法，并进行受控但有些自动化的部署。

当不同类型的插件和主题可以在文件系统或数据库中存储配置时，您如何处理工作和部署到开发，测试，登台和生产环境？我意识到答案可能是“不要使用WordPress”，但假设我必须，让我知道你的想法，

感谢您的帮助，

戴夫

Answer 1

到目前为止，我最终解决了这个问题：

源代码目录：

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 checkout任务，phing和phpunit等进行自动和手动构建......基本上，Hudson服务器根据你想要的内容从subversion中提取代码部署，rsync是要从CI服务器部署到目标服务器的文件。

或者，在从直接升级到生产的部署的情况下，Hudson rsync将文件从暂存，再到CI服务器，然后备份到生产。

我已经在hudson中为以下功能构建了作业：

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文件权限。

戴夫

Answer 2

对于我们使用GIT的文件系统，它运行良好。您可以为每个团队成员创建一个分支，然后将其合并到生产分支中。我们可以将我们的代码集成到任何麻烦中。

对于数据库，我一直倾销prod数据库并与大家共享（你甚至可以将它发送到GIT仓库，然后每个人都有最新的转储）。

Answer 3

我发现rollout非常有用。它是一项付费服务，但值得一试。没有脚本根本没有编码。只需注册并按照食谱进行操作。你完成了。此外，它还进行预部署检查，使您的部署非常顺利和轻松。

自动化Wordpress开发和部署

3 个答案: