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

接下来的另一个步骤是,一旦发布版本通过测试(比如Smoke测试),它就可以作为一个好的版本(比如Golden版本),您可以使用某种标记机制来标记所有进入创建Golden Image的人工制品(代码、安装脚本、生成文件、可安装文件等)。黄金构建可能稍后成为发布候选。

也许你已经这样做了,因为你没有提到我添加了我所观察到的。

我们就是这样做的。 测试人员自身的数据库仅在需要时重置。如果我们每周都自动刷新,那么

1. 我们将失去对bug症状的引用;如果发现了一个bug,但开发人员只在几周后(或仅仅在周末之后)查看它,那么该bug的所有内容都可能被破坏。
2. 测试人员可能正处于一个大型测试用例的中间(例如,需要1天以上的时间)
3. 我们有大量的单元测试正在针对一个数据库运行,每次执行集成构建时,数据库都会刷新(当然是自动刷新的)。

当做,
斯泰恩

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

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