4

我正在尝试使用 Phing 来自动化：

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

我认为在我的项目中添加一个构建文件夹并将我所有的构建配置文件和数据库增量放在该文件夹中是有意义的。并将所有内容提交到 SVN 存储库中。所以每个开发人员在从 svn 签出时都会得到更新的构建文件。并能够运行构建以使用新更改更新他的数据库。

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

我也计划使用 PHPUnderControl 实现持续集成，这样我就可以跟踪每个构建的结果，并在构建失败时得到通知。

那么，您认为这一切都有意义吗，还是您有其他更好的建议？

4

1 回答 1

10

你说的很有道理：它与我经常使用的非常接近（有时使用 ant，有时使用 phing，有时使用一些 shell 脚本）。

在build目录中，我会有这样的东西：

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

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

这可以通过importphing 的最后一个版本中存在的任务来完成（不确定它是否在稳定版本中——我正在使用 phing 的 SVN 签出来拥有这个，用于我目前正在处理的项目） .


但有一件事：你说你想从生产服务器部署到生产；我宁愿：

  • 在“开发”服务器上：
    • 从 SVN 导出
    • 压缩 JS/CSS 和所有这些
    • 创建一个 tar.gz 存档
  • 将该存档上传到生产服务器
  • 在“生产”服务器上：
    • 解压缩上传的存档
    • 更改几个符号链接以使用新版本的源（有关更多信息，请参阅我在这里给出的答案）
    • 更新数据库中必须做的事情

这个想法是：

  • 在生产服务器上做尽可能少的事情
    • 以防万一出现问题
    • 万一有一天，您的生产服务器无法访问 SVN 服务器
  • 拥有可以部署在多个生产服务器上的物理存档


哦，而且，作为旁注：您必须逐步编写某种“如何部署到生产”的文档！

这将在您度假的那一天非常有用，并且由于紧急修复错误而其他人必须部署到生产环境；-)

于 2010-01-04T10:47:46.390 回答