2010-01-04 13 views
4

我试图使用Phing自动化:在需要的时候你如何管理你的构建[使用Phing]过程?

  • 运行测试
  • 每个开发人员的机器上运行数据库迁移[dbdeply使用]
  • 部署到生产

我想在我的项目中添加一个构建文件夹并将所有构建配置文件和db变量存放在该文件夹中确实有意义。并将所有内容提交到SVN存储库。因此每位开发人员在从svn退房时都会得到更新的构建文件。并能够运行构建以使用新更改更新他的数据库。

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


我打算实现使用PHPUnderControl继续集成,所以我可以跟踪每个构建的结果,并在构建失败时得到通知。

所以,你认为这一切确实有意义,或者你有其他更好的建议吗?

+0

退房Arbitracker作为替代phpUnderControl的:HTTP:// WWW .arbitracker.org/news.html – Gordon 2010-01-04 10:44:56

+0

@戈登,谢谢我也会检查一下。 – Shreef 2010-01-04 13:41:49

回答

10

你说的有道理:它非常接近我经常使用的(有时用蚂蚁,有时用phing,有时用一些shell脚本)

build目录,我想有这样的事情:

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

有了一个build.xml文件中的每个子目录 - 包括所有其他build.xml文件,地处common目录,其用意就是在“普通”文件中放置尽可能多的“通用”代码,并且使每个环境特定的文件尽可能少地包含xml代码。

这可以存在于phing (不知道它在稳定版本的最后一个版本的import任务来完成 - 我使用phing的SVN结帐,有这一项,该项目我目前正在研究)


但有一件事:你说你想从生产服务器部署到生产;我宁愿,而不是:

  • “发展” 的服务器上:
    • 从SVN出口
    • 压缩JS/CSS和所有
    • 创建tar。GZ存档
  • 上传的是归档到生产服务器
  • “生产”服务器上:即上传档案
  • 变化的几个符号链接的使用新版本的
    • 未压缩来源(见我给here,更多的信息回答)
    • 更新什么在DB
  • 完成

的想法是到:

  • 以防万一做的几件事情,尽可能生产服务器
    • 上出了问题
    • 并且如果有一天,你的生产服务器无法访问SVN服务器
  • 有一个物理归档文件,可以在多个生产服务器上部署


哦,还有,作为一个旁注:你必须写某种“如何部署到生产”的文档,一步一步!

这将是真正有用的一天,你在度假,别人已经部署到生产,因为一个紧急漏洞修复;-)