6

我目前正在与一个分布在美国各地的团队一起开展一个相当大的项目。开发人员定期将代码提交到源存储库。我们有以下应用程序构建（全部由应用程序管理，没有手动流程）：

  1. 持续集成：监视器检查代码存储库是否已更新，如果是，它会进行构建并运行我们的单元测试套件。出现错误时，团队会收到电子邮件通知
  2. 每日构建：开发人员使用此构建来验证他们在实际应用程序服务器上的错误修复或新代码，如果“事情”成功，开发人员可能会解决任务。
  3. 每周构建：测试人员验证此构建中已解决的问题队列。这是一个更稳定的测试环境。
  4. 当前版本构建：用于潜在新用户的演示和开放测试平台。

每个构建都会刷新与其关联的数据库。这会清理数据并验证任何与新代码一起发生的数据库更改都被引入。我从我们的测试人员那里听到的一个担忧是，我们需要使用一些预期的测试数据预先填充每周构建数据库，而不是更通用的数据开发人员一起工作。这似乎是一个合理的关注/需求，并且是我们正在努力的事情。

我正在折腾我们正在做的事情，看看 SO 社区是否认为我们正在做的事情有任何差距，或者有任何顾虑。事情似乎运作良好，但感觉它可能会更好。你的意见？

4

3 回答 3

1

这几乎就是我们这样做的方式。测试人员本身的数据库仅按需重置。如果我们每周自动刷新，那么

  1. 我们将失去对错误症状的引用；如果发现了一个错误，但开发人员仅在几周后（或仅在周末之后）才查看它，那么该错误的所有证据可能已经消失
  2. 测试人员可能正在处理一个大的测试用例（例如需要超过 1 天）
  3. 我们有大量的单元测试正在针对每次执行集成构建时都会刷新（当然是自动）的数据库运行

问候，
Stijn

于 2010-02-23T14:05:17.347 回答
1

接下来的另一个步骤是，一旦发布版本通过了测试（比如冒烟测试），那么它就被认为是一个好的版本（比如黄金版本），并且您使用某种标签机制来标记所有的人工制品（代码、安装用于创建黄金映像的脚本、makefile、可安装文件等）。黄金版本可能会在以后或不会成为候选版本。

可能您已经在这样做了，因为您没有提到我添加了我观察到的内容。

于 2010-02-23T14:31:12.053 回答
0

我认为您有一个良好、全面的流程，只要它适合您的客户想要查看更新的时间。我可以看到的一个可能的差距是，您似乎无法在不到一周的时间内将关键的客户错误修复投入生产，因为您的测试构建是每周一次，然后您需要时间让测试人员进行验证修复。

如果您喜欢以不同的方式思考问题，请查看这篇关于持续部署的文章- 一开始可能有点难以接受这个概念，但它肯定有一些潜力。

于 2010-02-23T15:49:28.040 回答