关于应用实例管理的问题

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

问候，
斯蒂金

Answer 3

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

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