你如何管理你的构建[使用Phing]过程？ [英] How do you manage your build [using Phing] process?
问题描述
我要使用Phing自动化：
- 运行测试
- 运行DB每个开发人员机器上的迁移[使用dbdeply]
- 在需要时部署到生产中
在我的项目中添加一个构建文件夹并将所有我的构建配置文件和db deltas放在该文件夹中是有意义的。并将其全部提交到SVN存储库。所以每个开发人员在从svn签出时都会得到更新的构建文件。并且能够运行构建以更新他的数据库与新的更改。
在生产服务器：
我计划在那里添加另一个构建文件在svn中获取最新的标记版本，并执行CSS& JS压缩。
我计划使用PHPUnderControl继续实现集成，所以我可以跟踪每个
所以，你认为这一切是否有意义，或者你有其他更好的建议吗？
你说的话很有意义：它非常接近我经常使用 ，有时使用一些shell脚本）。
在 build 目录中，像这样：
build /
testing /
development /
staging /
production /
common /
有一个 文件，位于每个子目录中的文件 - 都包含位于 common 中的另一个 build.xml $ c>目录，其想法是在common build.xml 文件中尽可能多地提供通用代码，并具有每个环境特定的文件，包含尽可能少的xml代码。
这可以通过 import 任务存在于最后一个版本的phing 确保它在稳定版本 - 我使用的SVN检查phing，有这个，对于我目前正在处理的项目）。
但有一件事：你说你想从生产服务器部署到生产;我宁愿，而是：
- 在一个开发服务器：
- 从SVN导出
- 压缩JS / CSS及其所有
- 创建tar.gz归档文件
- 将该归档文件上传到生产服务器上的生产服务器
- ：
- 解压上传的档案
- 更改一对符号链接以使用新版本的来源（请参阅我给出的答案在这里，了解更多资讯）
- 更新DB中需要完成的操作
/ p>
- 在生产服务器上执行尽可能少的操作
> - 具有可部署在多个生产服务器上的物理存档
哦，而且，作为一个旁注：你必须一步一步地写一些如何部署到生产的文档。
这将是非常有用的您在度假的那天，由于紧急错误修复，其他人必须部署到生产环境中; - ）
I'm trying to use Phing to automate :
- running tests
- running DB migrations on each Developer machine [using dbdeply]
- deployment to production when needed
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.
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.
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?
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).
In the build directory, I would have something like this :
build/
testing/
development/
staging/
production/
common/
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.
This can be done with the import task that exists in the last version of phing (not sure it's in the stable version -- I'm using an SVN checkout of phing, to have this one, for the project I'm currently working on).
One thing, though : you say you want to deploy to production from the production server ; I would rather, instead :
- on a "development" server :
- export from SVN
- compress JS/CSS and all that
- create a tar.gz archive
- upload that archive to the production server
- on the "production" server :
- un-compress that uploaded archive
- change a couple of symlink to use the new version of the sources (see the answer I gave here, for more informations)
- update what has to be done in the DB
The idea being to :
- do as few things as possible on the production server
- just in case something goes wrong
- and in case, one day, your production server doesn't have access to the SVN server
- to have a physical archive that can be deployed on several production servers
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 ;-)
这篇关于你如何管理你的构建[使用Phing]过程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
