理想的开发/测试/ QA开发环境

Question

我正在努力重建我公司的开发/测试/ QA环境。我们有10-15名程序员参与了许多项目。它们目前都在PC上进行本地开发，并使用开发环境进行测试。我们目前没有QA环境，因此部署通常很痛苦，因为通常在某些内容发布后会发现错误。这就是我想象的：

1. 取消每个人的本地管理员权限，让每个人都在开发服务器上开发
2. 创建与我们的生产系统完全相同的QA环境。这将允许他们测试部署。
3. 创建一个比开发服务器更加锁定的新测试环境，以便进行正确的测试。

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

Answer 1

作为开发人员，如果您将我锁定在本地管理员权限之外，我真的很讨厌。

为什么要让每个人都在开发服务器上开发？您的员工是不是都在办公室环境中？

我唯一真正喜欢你的建议是QA服务器与生产环境相同。遗憾。

你应该：

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

Answer 2

这似乎是Continuous Integration在我心中的尖叫。在这里你可以拥有一个开发环境的第二部分，它不是某人的本地机器，但可用于显示当前正在进行的操作，并确保代码合并不会破坏事物。这与QA将使用的测试环境分开，并且应该有另一个环境作为另一个级别的准生产环境，因此如果有要发布的修补程序，则可以单独完成，而不是可能需要更多时间的更大版本让QA执行足够的回归以确保新功能不会破坏很多东西。

Answer 3

1. 别。这将是一个PITA，通过影响他们快速部署，调试代码以及​​并行运行多个版本代码的能力，会损害您的开发人员的工作效率。
   当然，你应该强迫他们在本地开发为非管理员，但这是另一个故事。
2. 是。事实上，我会更进一步，强制所有正在检入的代码到主存储库，以便在干净的服务器上进行自动部署。您还应该有一个这样的环境，其中也将部署要推送到生产的代码。
3. 是。这是第2项的一部分。

您要处理的第一项任务是确保您公司所使用的所有产品都有一个**部署包，您可以在一台干净的机器上以自动方式部署**。如果您没有这样的软件包，那么在尝试强制执行上述过程时会遇到很多麻烦，因为每次部署都需要人工干预，这将花费您的公司那么多的时间和资源，没有人会关心它。 / p>

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

Answer 4

我不是集中开发人员加入开发服务器的忠实粉丝。人们应该能够编辑和合并任何地方，无论他们碰巧在什么系统上。你想用这个解决什么问题？这个问题可能还有另一个解决方案。

QA服务器是必须的。您的QA团队需要一个可以打破不会影响开发的事情的地方。

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

Answer 5

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

• JetBrains TeamCity - 持续集成和构建，以及单元测试运行器
• Atlassian Jira - 问题跟踪和项目管理
• Atlassian Fisheye / Crucible - 代码审查和一般代码指标。
• VisualSVN服务器 - 源代码控制
• VisualSVN Client（与Visual Studio集成，非常值得）。
• JetBrains ReSharper - 程序员的工作效率和一些简洁的单元测试工具。

我不能足够推荐这些工具。 TeamCity通过将您的构建从开发人员的机器上移开并在一个干净，受控的环境中构建来处理您的“我们在发货后发现了该错误”。它还将运行单元测试并确保您始终具有可用的构建（通过命名和羞辱构建断路器）。

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

我认为其他项目是不言自明的，它们都有助于“最佳实践”，这将使您的商店在“乔尔测试”中走得更远。 Atlassian提供10个许可证，10美元一些产品，这是很难被击败的。

尽管如此，你的发展困境的解决方案至少部分是文化的。您可以将这些（或其他）工具放在适当的位置，但是您需要团队和管理层的支持，并且您需要解决您的实践以确保开发人员使用它们。一些再教育可能会被要求，因为草率的开发人员通常不喜欢被迫提升他们的游戏。我将从构建服务器开始，并坚持不会发布任何代码，除非它来自自动构建。很多好的做法都会失败。您可以考虑在适合您的组织时采用单元测试和代码审查 - 但计划从一开始就这样做。

Answer 6

如果你真的想简化一些事情，请看看持续部署概念，这个概念正变得非常流行。这是一个good introductory post;总体目标是使用严格的自动检查来从开发到生产部署，以消除错误。

完整的持续部署设置最初可能会有点麻烦，但您可以从尝试从开发到QA开始尝试。

Answer 7

请记住 - 没有可以在所有情况下应用的“理想”通用开发环境。通常，技术限制阻碍了这些想法的全面采用。作为一个多年来的知名承包商，我发现我工作的最糟糕的系统没有本地管理员权限，每次安装都需要调用技术支持，并且他们总是诅咒我们开发人员过多地询问它们。

我遇到的最佳方案是：如果您要删除本地管理员权限，请为其提供功能强大的本地托管虚拟机。他们应该在网络上有一个DMZ，这样他们就可以用VM做他们想要的任何。如果他们搞砸了，您可以简单地从文件中恢复VM。这个场景的重要之处在于使用GIT，Team Foundation Server，SVN等良好的源代码库。这就是开发应该完成的方式 - 除了实际输入代码之外，不依赖于开发人员工作站

此提示和其他提示的列表：

允许开发人员在其虚拟机（Internet访问，应用程序安装等）中完全自由

使用一个好的源代码控制存储库，每个开发人员可以随意分支。强制执行常量签入（例如每小时一次）并使用构建服务器（持续集成或“CI”）来检查损坏的构建。当构建中断时，CI服务器应该通过电子邮件向团队中的每个人发送电子邮件。

为每台本地计算机提供最佳资源。我听说4GB对于Visual Studio来说足够了。没有什么比真相更深。您可能决定坚持这一点，但相信我 - 当您的开发人员机器一遍又一遍地分页到磁盘时，因为每个构建占用大量内存，您每小时损失几分钟 - 每周小时 - 因为生产力损失，慢机器。

尽量不要瞧不起你的开发人员 - 他们会闻到它一英里的味道而又怨恨你（想要对心怀不满的开发人员删除源代码或引入错误负责？）。有可能他们是“草率开发者”的原因是因为公司中没有其他人能够管理人员。最好的团队由聪明，开放，受过良好教育的项目经理领导。他们在需要时得到他们需要的东西。与开发商的工资成本相比，软件的成本并不高 - 但我仍然听说这个或那个经理拒绝一个产品，因为它的成本很高。上次是XML Spy - 因为“Notepad就够了”。当然它会 - 就像腿足够而不是汽车，但我不想走到处都是该死的！

反对谷物 - 我实际上认为从所有开发者中删除管理员能力是一件好事，如果你可以创建一个具有最多能力的poweruser。我从团队中发现的最大问题是人们应用补丁或安装他们尚未与管理层清除的其他软件。上次有人安装ReSharper然后抱怨机器移动缓慢。他们有一台2GB的机器，而ReSharper 5需要至少4GB才能在Visual Studio 2010上运行。

另外 - 学会不使用鼠标进行开发。这是我所知道的一个激进概念，但鼠标比键盘快捷键慢。除非图标位于页面的角落，否则平均需要一两秒才能找到图标并单击。记住快捷方式更快。<​​/ p>