关于应用实例管理的问题

Question

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

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

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

我是在抛出我们正在做的事情，看看社会人士是否认为与我们的工作有任何差距，或是否有任何关注。事情似乎很顺利，但感觉可能会更好。你的想法？

Answer 1

接下来的另一个步骤是，一旦发布版本通过测试(比如烟雾测试)，它就被限定为一个良好的构建(比如黄金构建)，并且使用某种标记机制来标记所有的人工制品(代码、安装脚本、makefiles、installable等)。进入了黄金形象的创造。金色构建可能会成为稍后发布的候选版本，也可能不会。

也许你已经在做这件事了，因为你没有提到我补充了我观察到的内容。

Answer 2

我们就是这样做的。测试人员本身的DB仅在需要时才被重置。如果我们每周自动刷新这个

1. 我们将失去对bug症状的引用；如果发现了一个bug，但是开发人员只在几周后(或者仅仅在周末之后)查看它，那么该bug的所有缺陷可能已经消失。
2. 测试人员可能处于大型测试用例的中间(例如超过1天)。
3. 我们有大量的单元测试，这些测试是针对DB运行的，每次执行集成构建时，DB都会被刷新(当然是自动的)。

打招呼，

斯蒂金

Answer 3

我认为你有一个好的，全面的过程，只要它适合当你的客户想要看到更新。我看到的一个可能的差距是，您似乎无法在不到一周的时间内将关键的客户bug修复程序投入生产，因为您的测试构建是每周一次，因此您需要时间让测试人员验证该修复程序。

如果您想以不同的方式思考事物，那么请看一看连续部署上的这篇文章--一开始接受这个概念可能有点困难，但它肯定有一些潜力。