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

Question

我正在尝试使用Phing自动化以下过程：

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

我认为在我的项目中添加一个构建文件夹，并将所有构建配置文件和数据库差异文件放入该文件夹中，提交到SVN存储库中是有意义的。这样，每个开发者在从svn检出代码时都能获得最新的构建文件，并能运行构建以更新其数据库中的新更改。

在生产服务器上： 我计划添加另一个构建文件，在其中获取svn中的最新标记版本并执行CSS和JS压缩。

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

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

- Shreef

---

请尝试使用 Arbitracker 作为 phpUnderControl 的替代品：http://www.arbitracker.org/news.html - Gordon

Answer 1

在编程方面，你所说的很有道理：它与我经常使用的东西非常接近（有时候是用 ant，有时候是用 phing，有时候是用一些 shell 脚本）。

在“build”目录中，我会有类似于这样的东西：

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

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

可以使用import任务来完成此操作，该任务存在于phing的最新版本中（不确定它是否在稳定版本中，我正在使用phing的SVN检出版本，为我目前正在处理的项目使用此版本）。

但需要注意一件事：您说您想从生产服务器部署到生产环境；相反，我更愿意：

• 在“开发”服务器上：
  • 从SVN导出
  • 压缩JS/CSS和所有其他内容
  • 创建tar.gz归档文件
• 上传该归档文件到生产服务器
• 在“生产”服务器上：
  • 解压已上传的归档文件
  • 更改一些符号链接以使用源的新版本（有关详细信息，请参见我在此处给出的答案）
  • 更新必须在数据库中执行的操作

这样做的想法是：

• 尽可能少在生产服务器上执行操作
• 以防万一出了问题
• 以及，如果有一天，您的生产服务器无法访问SVN服务器
• 拥有一个物理存档，可以部署到多个生产服务器上

哦，顺便说一句: 您必须编写一些“如何部署到生产环境”的文档，逐步说明！

这将在您度假时非常有用，因为由于紧急错误修复而需要其他人部署到生产环境；-）

- Pascal MARTIN