Asp.net 理想的开发/测试/质量保证环境

我正在努力重建公司的开发/测试/质量保证环境。我们有10-15名程序员参与了许多项目。他们目前都在自己的PC上本地开发，并使用开发环境进行测试。我们目前没有QA环境，因此部署通常是一件痛苦的事情，因为bug通常是在某些东西上线后发现的。以下是我的设想：

取消每个人的本地管理员权限，让每个人都在开发服务器上开发

创建一个与我们的生产系统相同的QA环境。这将允许他们测试部署

创建一个比dev服务器更封闭的新测试环境，以便进行适当的测试

---

你的想法是什么？建立这样一个环境的最佳方式是什么？我们使用MS Visual Studio 2008开发ASP.NET应用程序（如果有帮助的话）。

作为一名开发人员，如果您将我锁定在本地管理员权限之外，我会非常讨厌

为什么让每个人都在开发服务器上开发？你的员工不是都在办公室吗

关于您的建议，我唯一真正喜欢的是与生产环境完全相同的QA服务器。对不起

你应该：

• 通过源代码控制管理代码
• 有一个专门的构建经理将构建推送到QA。在QA批准/业务签准/在此处插入业务流程后，构建经理将推动生产
• 希望您的数据库也有一个测试环境。DBA应该管理将数据库更改推送到生产环境中。开发人员在测试环境中创建，该环境是每个人都使用的另一台服务器上的SQL Server/随便什么
• 如果你使用MS产品-考虑让你的项目WDP（Web部署项目）。MSBuild与此集成，例如，您可以直接从TFS构建任务启动构建。增量构建、每日构建、仅手动构建——一旦正确设置，这真的很好

不要。这将是一个PITA，会影响开发人员快速部署、调试代码和并行运行多个版本代码的能力，从而影响您的开发人员的工作效率。
当然，您应该强制他们在本地开发为非管理员，但这是另一回事

对。事实上，我会更进一步，强制所有签入到主存储库的代码在干净的服务器上进行自动部署。您还应该有一个这样的环境，将要推送到生产环境中的代码也将在其中部署

对。这是第2项的一部分

您要完成的第一项任务是确保您公司的所有产品都有一个**部署包，您可以在一台干净的机器**上自动部署。如果您没有这样的软件包，那么您将很难强制执行上述过程，因为每次部署都需要手动干预，这将花费您公司太多的时间和资源，没有人会在意

---

第二项任务是为部署服务器提供最终配置并准备映像，任何人都可以在本地或虚拟机上部署映像。这将是任何测试的基准，并且应该尽可能接近实际的生产配置。

我不太喜欢将开发人员集中到开发服务器上。人们应该能够编辑和合并从任何地方，他们碰巧在任何系统上。你想用这个解决什么问题？这个问题可能还有另一个解决办法

QA服务器是必须的。您的QA团队需要一个地方，他们可以去打破不会影响开发的东西

---

我假设通过“测试”服务器，这实际上是一个可以放置夜间构建的地方，这样开发人员可以在发布到QA之前进行测试？这是一个非常好的主意，正如Cen所提到的，可以使用服务器构建任务的夜间构建来帮助这一过程。

这似乎是我心中迫切需要的。这是开发环境的第二部分，它不是某人的本地机器，但可以用来显示当前正在做什么，并确保代码合并不会破坏东西。这与QA将使用的测试环境是分开的，并且应该有另一个环境作为另一个级别的准生产环境，因此，如果有热修复程序要发布，这可以单独完成，而不是大型版本，后者可能需要更多时间让QA执行足够的回归，以确保新功能没有破坏很多东西。

我不会通过删除本地管理员权限来解决这个问题，这弊大于利，但我建议设置生成服务器以在受控环境中验证生成。我采用的工具集（我发现它对我和我的十几名志愿者团队非常有效）是：

• JetBrains TeamCity-持续集成和构建，以及单元测试运行程序
• Atlassian Jira-问题跟踪和项目管理
• Atlassian Fisheye/Crucible-代码审查和通用代码度量
• VisualSVN服务器-源代码控制
• VisualSVN客户端（与Visual Studio集成，非常值得）
• JetBrains ReSharper—程序员的生产力和一些简洁的单元测试工具

我对这些工具的推荐度太高了。TeamCity通过将您的构建从开发人员的机器上移开，并在一个干净、受控的环境中构建，来处理您的“发布后我们发现了bug”。它还将运行单元测试，并确保您始终拥有一个工作的构建（通过命名和羞辱构建破坏者）

Crucible是一款很有价值的产品，它可以让您轻松地进行同行代码审查，并进行全面审核，因此您可以验证它们是否正确