我们正在考虑在开发生命周期中添加另一台服务器，以便我们可以测试部署。
一些背景知识 我们使用ASP.NET和SQL Server 2005构建Web应用程序。团队中有4个开发人员，并且每两周发布一次。
这是我们目前的部署方法： 我们在Dev服务器上进行开发，并且每个开发案例都完成后，它将被添加到Staging服务器中，并在其中进行测试。当我们到达发布日期时，发布中的所有案例都从Staging服务器部署到Live服务器。
但问题是，只有当我们进行完整部署时，才会在发布日期部署到Live - 所有部署到Staging都是按案例完成的。这意味着我们一直在制作错误或跳过实时部署中的步骤（例如，在部署期间忘记锁定用户）。我们需要的是一种虚拟运行实时部署的方法。
我们正在考虑的是在发布过程中添加另一台服务器，所以......
当前服务器设置：开发服务器 - ＆gt;登台服务器 - ＆gt;实时服务器
潜在的服务器设置：开发服务器 - ＆gt;登台服务器 - ＆gt; Beta服务器（这是正确的名称吗？） - ＆gt;实时服务器
通过这种方式，我们可以在Beta服务器上练习每个完整部署，并为实际部署制定一系列步骤 - 希望我们的实时部署更加顺畅。我们还计划让客户访问Beta服务器以自行测试。
请让我知道你的想法。您是否这样做或者是否有其他方法在发布日期之前测试我们的部署？
答案 0 :(得分：3)
你走在正确的轨道上。
以下是我们的工作方式 - 其他人可能会采取不同的方式（但他们也可以回答您的问题，您可以自行决定）。
1）代码是在dev中构建的 - 这是不受控制的区域。
2）所有数据库更改都是脚本化的，并且所有.NET代码都内置在MSI中。我们将这些部署到Test中。它们也存储在特殊的地方，不会被搞乱。如果有任何问题，测试将找到它们，我们将调整脚本/使用修复程序创建新的MSI。
3）测试完成后，“预生产”环境将从实时恢复。它看起来像是一个相同的直播副本。最终版本将进入“预生产”阶段。部署应该正常工作，但这是确保它发挥作用的机会。如果没有，则调整部署并将“预生产”环境从实时中恢复，因此我们知道我们正在针对精确副本进行测试（没有必要针对您已经搞砸过的那个进行测试）与！）
4）如果发布有效（并且您通常会执行一些测试来检查所有组件），它就可以在现场运行了。
如果您重新运行数据库脚本，这会有所帮助。如果脚本因任何原因多次运行，请在再次执行此操作之前检测更改是否已存在。例如，如果您将一个配置值添加到表中，请检查以确保您还没有完成它，否则您可以多次添加它并激活您的数据。