asp.net - 开发和测试环境最佳实践？

Question

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

1. 您建议采用多少个层级以及每个层级的内容是什么？只是开发、测试和生产，或者可能是开发、测试、登台和生产？
2. 哪些类型的应用程序和/或服务器应在实际物理硬件上运行，哪些类型可以使用虚拟机？
3. 对于网站上的用户、网络/应用/数据库服务器上的网络开发人员以及数据库服务器上的数据库开发人员松散耦合，您采取了什么策略？
4. 开发人员如何保持“DRY”？ (请不要开除臭剂的玩笑；)
5. 将 Web、应用程序和数据库服务器放在自己的计算机上有哪些优点和缺点？将服务器放在不同的计算机上以最大程度地减少对计算机资源的争用是否会胜过将它们放在不同的计算机上可能引入的任何 NIC 和网络延迟？
6. 如何配置网络应用以最大程度地减少资源争用(例如虚拟目录、单独的应用程序池等)
7. 您如何以及多久刷新每一层的数据库？您只是刷新数据还是同时刷新数据和对象？

谢谢。

Answer 1

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

1) 取决于您的资源，但理想情况下我希望拥有 4 个。

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

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

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

&产品

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

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

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

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

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