您首选的 PHP 部署策略是什么？

小开

自动和盲目地将更改从存储库转移到生产服务器听起来很危险。如果您提交的代码包含回归 bug，因此您的生产应用程序出现故障，该怎么办？

但是，如果您想要一个用于 PHP 的持续集成系统，我想 Phing是 PHP 的最佳选择。不过，我还没有亲自测试过它，因为我使用了例如 scp 的手动方式。

小开

最佳答案

对于 PHP 来说，带有 Phing构建脚本的 SVN 是可行的方法。Phing 类似于蚂蚁，但是是用 PHP 编写的，这使得 PHP 开发人员更容易根据自己的需要进行修改。

我们的部署程序如下:

每个人都在同一台本地服务器上工作，每个开发人员在自己的机器上也有一个结帐。
提交触发一个后提交钩子，用于更新登台服务器。
如果测试传递-继续，则在登台服务器上运行。
运行 Phing 构建脚本:
关闭生产服务器，将域切换到“建设中”页面
在生产结帐时运行 SVN 更新
运行架构 deltas 脚本
做测试
如果测试失败，则运行回滚脚本
如果测试通过，服务器将路由回生产签出

还有 PhpUnderControl，它是一个持续集成服务器。说实话，我觉得这对网络项目没什么用。

小开

我使用阿帕奇蚂蚁部署到不同的目标(dev、 QA 和 live)。Ant 被设计用于 Java 部署，但是它为部署任意文件提供了一个非常有用的通用案例解决方案。

Xml 文件的语法非常容易学习——定义不同的目标及其在命令行上调用 ant 程序时运行的依赖项。

例如，我有 dev、 QA 和 live 的目标，每个目标都依赖于 cvsbuild 目标，它从我们的 CVS 服务器检出最新的 head 版本，将适当的文件复制到 build 目录(使用 fileset 标记) ，然后将 build 目录同步到适当的服务器。有一些怪癖需要学习，而且学习曲线并不是完全平坦的，但是我已经这样做了很多年，没有遇到任何麻烦，所以我建议你这样做，尽管我很好奇在这个帖子里我还会看到其他什么答案。

小开

我在服务器上有一个 SVN 发布分支的工作副本。更新站点(当没有模式更改时)与发出 SVN update 命令一样容易。我甚至都不用关掉网站。

小开

我使用 Git 手动完成工作。一个用于开发的存储库，将 git push --mirror改为公共回购，而活动服务器是从中提取的第三个回购。我想这部分和你自己的设置是一样的。

最大的区别在于，我几乎在每次修改时都使用分支(我现在有5个左右的分支) ，并且倾向于在它们之间来回切换。除了合并其他分支之外，主分支不会直接更改。

我直接从主分支运行活动服务器，当我完成另一个分支并准备合并它时，将服务器切换到该分支一段时间。如果坏了，还给主人只需要几秒钟。如果它工作，它将合并到 master 中，并且活动代码将得到更新。我认为在 SVN 中类似于有两个工作副本并通过符号链接指向活动副本。

小开

我知道 Phing现在已经被提到过几次了，但是我在 PhpUnderControl上运气很好。对于我们来说

在本地机器上检查分支机构的单个副本
测试分支，然后将其合并到 Trunk 中
提交到 Trunk 由 phpUnderControl 自动构建，运行测试并构建所有文档，应用数据库 delta
主干通过质量测试运行，然后合并到我们的 Stable 分支中
同样，phpUnderControl 自动构建 Stable，运行测试，并生成文档和更新数据库
当我们准备好推到生产环境时，我们运行一个 rsync 脚本，它备份 Product，更新数据库，然后向上推文件。Rsync 命令是手动调用的，这样我们就可以确保有人在监视这个促销活动。

小开

我目前正在部署 PHP 使用 Git。用 Git 的最新副本更新我的生产服务器所需要的只是一个简单的 Git 推送生产。它简单而快速，因为 Git 足够聪明，只发送差异，而不是重新发送整个项目。它还有助于在 Web 服务器上保存存储库的冗余副本，以防我这边的硬件出现故障(尽管为了安全起见，我也推送到 GitHub)。

小开

如果您能够忍受 xml 配置文件的痛苦，那么 Phing 可能是您最好的选择。Symfony 框架有自己的 rake (pake)端口，这个端口工作得很好，但是与 Symfony 的其他部分耦合得相当紧密(尽管您可以将它们分开)。

另一种选择是使用 Capistrano。显然，它不能像 Ruby 那样很好地与 PHP 集成，但是您仍然可以在很多方面使用它。

最后，您总是可以编写 shell 脚本。

小开

我们使用韦比斯特拉诺，一个 Capistrano 的网页前端，并且对它非常满意。

Webistrano 允许从 SVN、 GIT 等进行多阶段、多环境的部署。它具有内置的回滚支持，支持独立的服务器角色，如 web、 db、 app 等，并且可以并行部署。它允许您在多个级别(比如每个阶段)覆盖配置参数，并记录每个部署的结果，还可以选择通过邮件发送。

尽管 Capistrano 和 Webistrano 都是 Ruby 应用程序，但是部署“菜谱”的语法对于任何 PHP 程序员来说都足够简单和强大。Capistrano 最初是为 RubyonRails 项目构建的，但很容易适应 PHP 项目。

一旦配置好，非程序员甚至可以很容易地使用它，比如部署临时版本的测试人员。

为了提供尽可能快的部署，我们安装了 Fast _ remote _ cache 快速远程缓存方法，它更新远程服务器上的 svn 工作副本缓存，然后对结果进行硬链接。

小开

我想 SVN 的部署方式不是很好，因为:

你需要向全世界开放 SVN 访问

在生产 Web 服务器中有许多

我认为 Phing 生成一个分支 + 将所有 js/css + 置换 stage config + ssh 上传到所有 www 服务器是更好的方法。

Ssh 到10 www server 和 svn up 也是一个麻烦。

小开

Http://controltier.org/wiki/main_page

我们将使用它进行多服务器部署和维护。

小开

晚了一年，但是..。在我的例子中，部署不是自动的，我发现自动部署代码和运行数据库迁移脚本是很危险的。

相反，subversion 钩子只用于部署到测试/登台服务器。代码在迭代结束时被部署到生产环境，在运行测试并确保一切正常之后。对于部署本身，我使用一个定制的 Makefile，它使用 rsync 来传输文件。Makefile 还可以在远程服务器上运行迁移脚本，暂停/恢复 Web 和数据库服务器。

小开

在我的工作中，我和我的团队为 capistrano 的部署开发了一个面向 Phing 的替代程序，我们还整合了一些可用于 Phing 的好东西，比如 PHPUnit 测试、 phpcs 和 PHPDocumentor。我们已经把它做成了一个 git repo，它可以作为 git 中的子模块添加到项目中，并且工作得非常好。我已经将它附加到了一些项目中，它的模块化程度足以让它在我们的任何一个环境中(分段、测试、生产等等)轻松地与任何一个项目一起工作。.).

使用 phing 构建脚本，您可以从命令行手动运行它们，我还成功地使用 Hudson 和现在的 Jenkins ci 实现了构建/部署例程的自动化。

我现在不能发布任何链接，因为回购还没有公开，但我已经被告知，我们将开放源码有时很快，所以请随时与我联系，如果你有兴趣或如果你有任何问题，自动部署与 phing 和 git。

小开

我来晚了，不过我想和你分享一下我们的方法。我们使用 Phing 和 Phingistrano，它通过预构建的构建文件为 Phing 提供了类似 Capistrano 的功能。它非常酷，但是只有当您现在使用 Git 时才能工作。

小开

自制部署脚本的一种替代方法是将其部署到平台即服务(Platform-as-a-service) ，这种方法为您抽象出许多工作。PaaS 通常会提供自己的代码部署工具，以及可伸缩性、容错性(例如，当硬件出现故障时不会出现故障) ，通常还会提供一个用于监视、日志检查等的很棒的工具包。部署到一个已知的良好配置还有一个好处，这个配置将随着时间的推移保持最新(对您来说减少了一个麻烦)。

我推荐的 PaaS 是 DotCloud，除了 PHP (看看他们的 PHP 快速启动) ，它还可以部署 MySQL、 MongoDB 和一大堆其他服务。它还有一些好东西，比如零停机部署、即时回滚、对 SSL 和 websocket 的完全支持等等。还有一个免费的，总是不错的:)

当然，我有点偏见，因为我在那里工作！除了 dotCloud 之外，其他值得一试的选项还有 Pagodabox 和  (现在是 Engine Yard 的一部分)。

希望这个能帮上忙！

所罗门

您首选的 PHP 部署策略是什么？

进一步资料