php - 你如何管理你的构建 [使用 Phing] 过程？

Question

我正在尝试使用 Phing 来实现自动化:

• 运行测试
• 在每台开发人员机器上运行数据库迁移 [使用 dbdeply]
• 在需要时部署到生产环境

我认为在我的项目中添加一个构建文件夹并将我所有的构建配置文件和数据库增量放入该文件夹中确实有意义。并将所有这些提交到 SVN 存储库中。所以每个开发人员在从 svn checkout 时都会得到更新的构建文件。并能够运行构建以使用新更改更新他的数据库。

在生产服务器上:我打算在那里添加另一个构建文件，以在 svn 中获取最新的标记版本并执行 CSS 和 JS 压缩。

---

我还计划使用 PHPUnderControl 实现持续集成，这样我就可以跟踪每次构建的结果，并在构建失败时得到通知。

那么，您认为这一切是否有意义，或者您还有其他更好的建议吗？

Answer 1

您说的很有道理:它与我经常使用的非常接近(有时使用 ant，有时使用 phing，有时使用一些 shell 脚本)。

在 build 目录中，我会有这样的东西:

build/
    testing/
    development/
    staging/
    production/
    common/

每个子目录中有一个 build.xml 文件——所有子目录都包含另一个 build.xml 文件，位于 common 目录中，想法是将尽可能多的“通用”代码放入“通用”build.xml 文件中，并让每个环境特定的文件包含尽可能少的 xml 代码。

这可以通过 import 来完成phing 的最新版本中存在的任务(不确定它是否在稳定版本中——我正在使用 phing 的 SVN check out ，为了拥有这个，用于我当前正在处理的项目).

不过有一件事:你说你想从生产服务器部署到生产环境；相反，我宁愿:

• 在“开发”服务器上:
  • 从SVN导出
  • 压缩 JS/CSS 等
  • 创建一个 tar.gz 存档
• 将该存档上传到生产服务器
• 在“生产”服务器上:
  • 解压缩上传的存档
  • 更改几个符号链接(symbolic link)以使用新版本的源代码(有关更多信息，请参阅我给出的答案 here)
  • 更新数据库中必须完成的操作

想法是:

• 在生产服务器上做尽可能少的事情
  • 以防出现问题
  • 万一有一天，您的生产服务器无法访问 SVN 服务器
• 拥有一个可以部署在多个生产服务器上的物理存档

哦，还有，作为旁注:您必须逐步编写某种“如何部署到生产环境”的文档!

这将在您放假的那一天非常有用，并且由于紧急错误修复而其他人必须部署到生产环境；-)