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

Question

这个问题是针对ASP.NET和Server开发人员的。在建立您的开发和测试环境方面，您的最佳实践是什么？我对以下问题很感兴趣：

1. ，您推荐了多少层，以及每个层上发生了什么？仅仅是开发、测试和生产，或者可能是dev、test、暂存和production?
2. Which类型的应用程序和/或服务器应该在实际的物理硬件上运行，而这些应用程序和/或服务器可以摆脱VM？
3. --您对从网站松散耦合的用户、从web/app/DB服务器的web开发人员和从DB服务器的DB开发人员来说是什么策略？
4. 如何保持“干燥”？(请不要开除臭剂玩笑；)
5. 在他们自己的机器上安装web、应用程序和DB服务器有什么好处和缺点？是否将服务器放在不同的机器上以减少对机器资源的争用超过可能通过将它们放在不同的machines?
6. How上而引入的任何NIC和网络延迟?您是否配置web应用程序以减少对资源的竞争(例如虚拟目录、单独的应用程序池等)？
7. 如何以及多久在每个层上刷新数据库？您只是刷新数据还是同时刷新数据和对象？

谢谢。

Answer 1

我不能对所有这些都发表评论，但以下是我发现在我的经验中最有效的方法。

( 1)取决于你的资源，但理想的情况是我喜欢拥有4种。

Dev是超灵活的，并由您的开发团队拥有。它可以得到更新，只要他们认为是最好的，或功能完成。

QA是根据您的流程按计划或交付更新的。如果您在测试阶段做了瀑布更新，那么如果您执行迭代敏捷，那么每次迭代都会更新它。它应该模仿尽可能接近的刺激，但是你也许可以通过一些妥协而逃脱(见第二)

分期应该在每一种方式上都是相同的。如果可能的话，它甚至应该使用实际的生产数据(可能是从最近对真实生产环境的备份中恢复的)。在任何版本发布之前，应该使用它进行验收测试。

& Prod

2) Dev通常在VM上。大多数情况下QA也能做到。分期和prod应该匹配。我以前见过人们在VM上运行驱动程序，这取决于您的资源和对应用程序的需求。

3)我们的devs在本地SQL服务器上使用prod备份进行开发。这使每个人都远离中央dev SQL服务器。Dev和dev sql是单独的框(只是出于必要，它们管理着一堆项目)。QA、阶段和Prod也是如此。

4)大量的测试和交流。如果你有一个中小型的团队，这并不难。如果你有很多团队，比如scrum，正式的代码评审，以及保持团队间沟通的东西。不要像建议的修复一样对待干燥的问题，把它们当作需要修复的bug来对待。与预先编写代码相比，您将花费更多的时间来维护代码，因此将维护视为一等公民，并确保管理层参与其中。

5和6)实际上没有资格发表评论

7)开发团队需要的时候，根据部署情况进行QA和计划的更新。QA是每个迭代/ sprint，阶段和Prod是每个版本。