关于应用程序实例管理的问题

Question

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

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

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

我正在放弃我们正在做的事情，看看 SO 社区是否认为我们正在做的事情有任何差距，或者有任何担忧。事情似乎进展顺利，但感觉还可以更好。你的想法？

Answer 1

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

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

Answer 2

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

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

，
斯泰因

Answer 3

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

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