你如何管理你的构建[使用 Phing] 过程?
我正在尝试使用 Phing 来自动化:
I'm trying to use Phing to automate :
- 运行测试
- 在每台 Developer 机器上运行数据库迁移 [使用 dbdeply]
- 在需要时部署到生产环境
我认为在我的项目中添加一个构建文件夹并将我所有的构建配置文件和数据库增量放在该文件夹中是有意义的.并将所有内容提交到 SVN 存储库中.所以每个开发人员在从 svn 签出时都会得到更新的构建文件.并能够运行构建以使用新更改更新他的数据库.
I think it does make sense to add a build folder in my project and put all my build configuration files and db deltas in that folder. and commit all that into the SVN repository. so every developer will get the updated build files when he check-out from svn. and be able to run the build to update his DB with the new changes.
在生产服务器上:我打算在那里添加另一个构建文件以在 svn 中获取最新的 Tagged 版本并执行 CSS &JS 压缩.
on the production server: I was planning to add another build file there to get the latest Tagged version in svn and perform CSS & JS compression.
我也计划使用 PHPUnderControl 实现持续集成，因此我可以跟踪每次构建的结果并在构建失败时收到通知.
I was planning to implement continues integration using PHPUnderControl too, so I can keep track of the result of each build and get notified whenever the build fails.
那么，您认为这一切都有意义吗，或者您还有其他更好的建议吗?
so, do you think this all does make sense, or you do have other better suggestions?
推荐答案
你说的很有道理:它非常接近我经常使用的(有时使用ant，有时使用phing，有时使用一些shell脚本).
What you say makes sense : it's pretty close to what I often use (sometimes with ant, sometimes with phing, and sometimes with some shell-scripts).
在 build 目录中，我会有这样的东西:
In the build directory, I would have something like this :
build/
testing/
development/
staging/
production/
common/
每个子目录中都有一个 build.xml 文件 -- 所有子目录都包含另一个 build.xml 文件，位于 common 目录中，想法是将尽可能多的通用"代码放在通用"build.xml 文件中，并拥有每个环境的特定文件，其中包含尽可能少的 xml 代码.
With one build.xml file in each sub-directory -- all including another build.xml file, located in the common directory, the idea being to put as much "common" code as possible in the "common" build.xml file, and to have per-environment specific files, that contain as few xml code as possible.
这可以通过 来完成phing 最新版本中存在的 import 任务(不确定它是否在稳定版本中——我正在使用 phing 的 SVN 签出，来拥有这个，用于我的项目'目前正在工作).
但有一件事:你说你想从生产服务器部署到生产；我宁愿，而不是:
One thing, though : you say you want to deploy to production from the production server ; I would rather, instead :
- 在开发"服务器上:
- 从 SVN 导出
- 压缩 JS/CSS 等
- 创建一个 tar.gz 存档
- 解压缩上传的存档
- 更改几个符号链接以使用新版本的源代码(请参阅我给出的答案 这里，了解更多信息)
- 更新数据库中必须做的事情
想法是:
- 在生产服务器上做尽可能少的事情
- 以防万一出现问题
- 万一有一天，您的生产服务器无法访问 SVN 服务器
哦，而且，作为旁注:您必须逐步编写某种如何部署到生产"的文档！
Oh, and, as a sidenote : you have to write some kind of documentation of "how to deploy to production", step by step !这在您放假的那一天非常有用，并且由于紧急修复错误而其他人必须部署到生产环境；-)
This will be really useful the day you are in holiday and someone else has to deploy to production because of an urgent bug-fix ;-)
相关文章