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

时间:2010-07-07 18:03:36

标签: asp.net sql-server sql-server-2005

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

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

1 个答案:

答案 0 :(得分:2)

我无法对所有这些发表评论,但这是我发现在我的经历中最有效的方法。

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

Dev非常灵活,由您的开发团队拥有。只要感觉最好或功能完成,它就可以更新。

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

分段应该在各方面都相同。它应该尽可能使用真实的生产数据(可能从最近的真实生产环境备份中恢复。)它应该在任何发布之前用于验收测试。

&安培;生产

2)Dev通常可以在VM上。 QA在大多数情况下都可以。分期和刺激应该匹配。我之前看到人们对虚拟机进行了生产,这取决于你的资源和你的应用程序的需求。

3)我们的开发人员在本地SQL服务器上使用prod备份进行开发。这使每个人都不在中央开发SQL服务器上。 Dev web和dev sql是单独的框(只是出于必要,他们管理一堆项目。)与QA,Staging和Prod相同。

4)大量的测试和沟通。如果你有一个小型/中型团队,这并不难。如果你有很多团队看起来像scrum,正式的代码审查,以及在团队之间保持沟通的东西。不要将DRY问题视为建议的修复,将其视为错误,需要修复。您将花费更多时间来维护代码而不是预先编写代码,因此将维护视为一等公民,并确保管理层参与其中。

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

7)每当团队需要时,开发人员需要根据部署进行QA和计划。 QA是每次迭代/冲刺,Staging和Prod是每次发布。