关于应用实例管理的问题

Question

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

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

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

我正在抛弃我们正在做的事情，看看SO社区是否与我们正在做的事情有任何差距，或者有任何疑虑。事情似乎运作良好，但它感觉更好。你的想法？

Answer 1

这就是我们这样做的方式。 测试人员自己的数据库只能按需重置。如果我们每周自动刷新一次，那么

1. 我们会失去对bug症状的引用;如果发现了一个错误，但开发人员只在几周后（或者仅仅是在周末之后）查看它，那么该错误的所有可能性都会消失。
2. 测试人员可能正处于一个大型测试案例中（例如，持续时间超过1天）
3. 我们有大量针对数据库运行的单元测试，每次执行集成构建时都会刷新（当然是自动）

的问候，
斯泰恩

Answer 2

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

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

Answer 3

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

如果你想以不同的方式思考问题，请看continuous deployment上的这篇文章 - 一开始可能有点难以接受这个概念，但它肯定有一些潜力。