构建服务器最佳实践

时间:2009-01-07 20:55:41

标签: build-process build-automation build-server

我听说google有一些像这样的自动化过程:

  • 办理登机手续时,您的代码会被检入临时位置。
  • 它已建成。
  • 样式检查运行。
  • 测试运行。
  • 如果没有问题,代码将转到实际存储库。
  • 您会收到一封电子邮件,其中包含测试结果,效果图表,样式检查结果以及您的代码是否已签入。

因此,如果您想了解自己是否破坏了某些内容或获得了预期的出色表现,您只需登记并收到一封电子邮件,告诉您需要了解的内容。

您最喜欢的构建服务器最佳实践是什么?

3 个答案:

答案 0 :(得分:5)

您所描述的谷歌是每个基本构建过程的作用。具体项目可能还有其他需求,例如 - 我们如何将Web应用程序从登台部署到生产部门:

  • 构建开始
  • 实时网站脱机(Apache重定向到持有“正在建设中”页面的不同目录)
  • 为生产服务器运行SVN更新
  • 运行数据库架构增量
  • 针对更新的源和架构运行测试
  • 如果失败:运行回滚(SVN还原和数据库模式UNDO)
  • 网站重新上线
  • 构建结束

答案 1 :(得分:1)

在java平台上,我尝试了每一个主要的CI系统。我的提示是支付用于商业支持的解决方案是我见过的最便宜的构建系统。这些事情需要时间来维护,支持和排除故障。特别是随着大量的构建一直在运行。

答案 2 :(得分:1)

您提供的示例工作流程类似于TeamCity提议的工作流程。这个想法是:

  1. 代码
  2. 签入以“预测试”
  3. CI服务器测试“预提交”
  4. 如果(且仅当)测试通过, CI服务器提交代码更改为主仓库
  5. 这是一场宗教战争,但我更喜欢:

    1. 代码 - 测试 - 重构(循环)
    2. 提交
    3. CI服务器验证您的提交
    4. 每个负责任的程序员都应该在提交之前运行所有测试。

      第一种方式的主要论点是它保证SCM中没有破坏的代码。但是,我认为:

      • 您应该信任您的开发人员在提交之前进行测试
      • 如果测试需要很长时间,问题是您的测试速度慢,而不是工作流程
      • 开发人员热衷于快速测试
      • 依靠CI服务器运行测试会为您提供错误的安全感