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 Server ( http://hudson-ci.org/ ) 使用 subversion checkout 任务、phing 和 phpunit 等进行自动化和手动构建...基本上，Hudson 服务器根据什么从 subversion 中提取代码您要部署，它会将要从 CI 服务器部署到目标服务器的文件 rsync。

或者，在从登台直接部署到生产环境的情况下，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 checkin 时进行自动化部署。

这种设置允许组织中具有不同技能集（主要是 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 回答