【问题标题】：How do you manage your build [using Phing] process?你如何管理你的构建[使用 Phing] 过程？
【发布时间】：2010-01-04 18:52:51
【问题描述】：
我正在尝试使用 Phing 来自动化：
- 运行测试
- 在每台 Developer 机器上运行数据库迁移 [使用 dbdeply]
- 在需要时部署到生产环境
我认为在我的项目中添加一个构建文件夹并将我的所有构建配置文件和数据库增量放在该文件夹中是有意义的。并将所有内容提交到 SVN 存储库中。所以每个开发人员在从 svn 签出时都会得到更新的构建文件。并能够运行构建以使用新更改更新他的数据库。
在生产服务器上：
我打算在那里添加另一个构建文件以在 svn 中获取最新的 Tagged 版本并执行 CSS 和 JS 压缩。
我也计划使用 PHPUnderControl 实现持续集成，因此我可以跟踪每次构建的结果并在构建失败时收到通知。
那么，您认为这一切都有意义吗，或者您还有其他更好的建议吗？
【问题讨论】：
标签：
php
build
continuous-integration
phing
phpundercontrol
【解决方案1】：
你说的很有道理：它非常接近我经常使用的（有时使用 ant，有时使用 phing，有时使用一些 shell 脚本）。
在build 目录中，我会有这样的东西：
build/
testing/
development/
staging/
production/
common/
在每个子目录中都有一个build.xml 文件——所有这些都包括另一个位于common 目录中的build.xml 文件，其想法是在“common”中放置尽可能多的“通用”代码build.xml 文件，并拥有每个环境的特定文件，其中包含尽可能少的 xml 代码。
这可以通过 phing 的最后一个版本中存在的 import 任务来完成 （不确定它是否在稳定版本中——我正在使用 phing 的 SVN 签出来拥有这个，因为我目前正在进行的项目）。
但有一件事：你说你想从生产服务器部署到生产；我宁愿，而不是：
- 在“开发”服务器上：
- 从 SVN 导出
- 压缩 JS/CSS 等
- 创建一个 tar.gz 存档
- 将该存档上传到生产服务器
- 在“生产”服务器上：
- 解压缩上传的存档
- 更改几个符号链接以使用新版本的源代码（有关更多信息，请参阅我给 here 的答案）
- 更新必须在数据库中完成的操作
想法是：
- 在生产服务器上做尽可能少的事情
- 以防万一出现问题
- 万一有一天，您的生产服务器无法访问 SVN 服务器
- 拥有可以部署在多个生产服务器上的物理存档
哦，而且，作为旁注：您必须逐步编写某种“如何部署到生产”的文档！
这在您放假的那一天非常有用，并且由于紧急修复错误而其他人必须部署到生产环境；-)