开发和测试环境最佳实践？

Question

这个问题适用于ASP.NET和SQL Server开发人员.在设置开发和测试环境方面,您的最佳实践是什么？我对以下问题感兴趣:

1. 您推荐多少层以及每层上发生了什么？只是开发,测试和生产,或者开发,测试,升级和生产？
2. 哪些类型的应用程序和/或服务器应该在实际的物理硬件上运行,哪些可以通过VM运行？
3. 您从网站,Web开发人员,他们的Web/app/DB服务器以及DB开发人员从他们的数据库服务器松散耦合用户的策略是什么？
4. 开发商如何保持"干"？(请不要除臭笑话;)
5. 将Web,app和DB服务器放在自己的机器上有什么优缺点？是否将服务器放在不同的计算机上以最大程度地减少对计算机资源的争用,是否会因将它们放在不同的计算机上而引入任何NIC和网络延迟？
6. 如何配置Web应用程序以最大限度地减少对资源的争用(例如,虚拟目录,单独的应用程序池等)
7. 您在每个层上刷新数据库的方式和频率如何？您只是刷新数据或数据和对象吗？

谢谢.

Answer 1

我无法对所有这些进行评论，但这是我根据我的经验发现最有效的。

1) 取决于你的资源，但理想情况下我喜欢有 4 个。

开发非常灵活，并且由您的开发团队拥有。当他们认为最好或功能完成时，它可以得到更新。

QA 根据您的流程按计划或交付进行更新。如果你做瀑布式，它会在测试阶段更新，如果你做迭代式敏捷，它会在每次迭代时更新。它应该尽可能地模仿产品，但你也许可以通过一些妥协来逃脱（参见#2）

分期在各个方面都应该与产品相同。如果可能的话，它甚至应该使用真实的生产数据（可能从真实生产环境的最近备份中恢复）。它应该在任何发布之前用于验收测试。

及产品

2）开发通常可以在虚拟机上。大多数时候，QA 也可以。分期和产品应该匹配。我以前见过人们在虚拟机上运行产品，这取决于您的资源和对应用程序的需求。

3) 我们的开发人员使用本地 SQL 服务器上的产品备份进行开发。这使得每个人都远离中央开发 SQL 服务器。Dev web 和 dev sql 是独立的盒子（只是出于需要，它们管理一堆项目。）与 QA、Staging 和 Prod 相同。

4）大量的测试和沟通。如果您有一个小型/中型团队，这并不是那么困难。如果你有很多团队，会考虑诸如 scrum、正式代码审查之类的东西，以保持团队之间的沟通。不要将 DRY 问题视为建议的修复，而是将它们视为需要修复的错误。您将花费更多的时间来维护代码，而不是预先编写代码，因此将维护视为一等公民，并确保管理层同意这一点。

5 & 6) 没有资格发表评论

7) 每当团队需要时进行开发，根据部署按计划进行质量检查和升级。QA 是每次迭代/冲刺，Staging 和 Prod 是每次发布。