自动化 WordPress 开发和部署
有没有人曾经与不同地点的多个开发人员一起开发过 WordPress 项目？是否有关于分布式开发团队和自动化部署的最佳实践？
我有一个由不同程度的开发人员组成的团队，包括插件开发人员、主题开发人员和简单的 CSS 样式调整人员，分布在几个不同的地点，我希望建立一个良好的系统，让每个人都能够处理各自的部分，持续部署更改而不干扰其他人的代码。
目前系统正在运行WordPress-MU的安装，最终将升级到3.0。理想情况下，我们会将主题和插件存储在源代码管理中，并且由于对核心 WordPress 代码进行了一些修改，因此它也必须进入存储库。我无法找出构建存储库并进行受控但某种程度上自动化的部署的最佳方法。
当不同类型的插件和主题可能将配置存储在文件系统或数据库中时，您如何处理在开发、测试、登台和生产环境中的工作和部署？我知道答案可能是“不要使用 WordPress”，但假设我必须这样做，请告诉我您的想法，
谢谢您的帮助，
戴夫
Has anyone ever worked on a WordPress project with multiple developers in different locations? Are there best practices around distributed development teams and automated deployments?
I have a team of varying degrees of developers, including plugin developers, theme developers, and simple CSS style tweakers, in a few different locations, and I would like to setup a good system for everyone to be able to work on their separate pieces and continuously deploy changes without disturbing anyone else's code.
The system is running an installation of WordPress-MU at the moment, and it will eventually be upgraded to 3.0. Ideally, we would store the themes and plugins in source control, and since a few modifications have been made to the core WordPress code, it has to go into the repository as well. I'm having trouble figuring out the best way to structure the repository and do controlled but somewhat automated deployments.
How do you handle working in and deploying to development, testing, staging, and production environments, when different types of plugins and themes may store configurations on the file system or in the database? I realize the answer may be "Don't use WordPress," but assuming I have to, let me know what you think,
Thanks for your help,
Dave
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
到目前为止，我最终解决这个问题的方法如下：
源代码目录：
我正在使用 Hudson CI Server (http://hudson -ci.org/）使用 subversion 签出任务、phing 和 phpunit 等进行自动和手动构建...基本上，Hudson 服务器根据您想要部署的内容从 subversion 中提取代码，并且它 rsync要从 CI 服务器部署到目标服务器的文件。
或者，在从暂存直接部署到生产的情况下，Hudson rsync 将文件从暂存转移到 CI 服务器，然后备份到生产。
我在 hudson 中为以下功能构建了作业设置：
hudson 作业还能够部署特定于环境的 PHP 文件（例如 wp-config.php、db-config.php）以及 Apache 和 MySQL 配置文件到每台服务器上的正确位置。在某些情况下，我们部署到多个 Web 服务器和多个数据库服务器，并且大多数构建配置都是通过上面提到的 phing 构建文件和 .properties 文件来处理的。
将来，当我们有了开发集成环境时，我们可能会在任何代码的 svn checkin 上进行自动化部署。
这种设置允许组织中具有不同技能（主要是 CSS/HTML 与 PHP）的不同开发人员单独工作，并将他们的代码更改快速转移到适当的环境，而无需涉及一堆不必要的人员。 Hudson 允许我锁定不同的部署作业，这样只有合适的人才能配置它们并启动它们。
这是我所设置的高级概述，请告诉我您的想法。此设置最大的烦恼是密钥对、用户帐户以及所有不同服务器上 rsync 的文件权限。
戴夫
Here is how I ended up solving this issue so far:
Source code directories:
I am using Hudson CI Server (http://hudson-ci.org/) to to automated and manual builds using subversion checkout tasks, phing, and phpunit, etc... Basically, the Hudson server pulls code from subversion depending on what you want to deploy, and it rsync's the files to be deployed from the CI server out to the destination server.
Or, in the case of a deployment from staging directly to production, Hudson rsync's the files from staging, down to the CI server, and then back up to production.
I have build jobs setup in hudson for the following pieces of functionality:
The hudson jobs also have the ability to deploy environment specific PHP files (e.g. wp-config.php, db-config.php), as well as Apache and MySQL config files to the proper locations on each server. In some cases, we deploy to multiple web servers, and multiple database servers, and most of the build configuration is taken care of through the phing build file and the .properties files mentioned above.
In the future, when we have a development integration environment, we will probably do automated deployments upon svn checkin of any code.
This setup allows different developers in the organization with different skillsets (CSS/HTML vs. PHP mainly) to work separately and get their code changes out to the proper environments quickly without involving a bunch of unnecessary people. Hudson allows me to lock down different deployment jobs so only the right people have access to configure them and kick them off.
That's kind of a high level overview of what I have setup, let me know what you think. The biggest annoyances with this setup was keypairs, user accounts, and file permissions with rsync across all the different servers.
Dave
对于文件系统，我们使用 GIT，它运行得很好。您可以为每个团队成员创建一个分支，然后将其合并到生产分支中。我们可以毫无麻烦地保持我们的代码集成。
对于数据库，我不断转储产品数据库并与每个人共享（您甚至可以将其发送到 GIT 存储库，然后每个人都会拥有最新的转储）。
For the filesystem we use GIT and it works very well. You can have a branch for each team member and then merge it into the production branch. We can keep our code integrated whitout any troubles.
For the database I keep dumping the prod database and sharing with everybody (you can even send it to the GIT repo and then everyone will have the lastest dump).
我发现 rollout 非常有用。它是一项付费服务，但值得尝试。没有脚本 根本没有编码。只需注册并按照那里的食谱进行操作即可。你完成了。它还会进行预部署检查，使您的部署非常顺利和轻松。
I found rollout to be quite usefull. Its a paid service but its worth trying. No Scripting No coding at all. Just signup and follow the recipe out there. You are done. Also it does pre deployment checks that makes your deployment quite smooth and easy.