- 确保您的开发环境是生产环境的快照。
- 确保您的构建/部署系统在Dev中的工作方式与Prod。中相同。
- 确保每个部署都与所有其他已部署的应用程序/服务隔离。
- 确保开发/测试环境可以轻松访问prod数据
要么是只读的，要么是要摆弄的副本。
我工作过的一家公司的每个盒子Dev / Test / Prod都有相同的基本图像。
现在我们的开发人员往往变得怪异，并安装我们自己的自定义工具等（我从未遇到过没有自定义环境的开发人员），但这个公司没问题：构建工具将构建和部署代码在您的盒子上与代码在生产中部署的方式相同（这样您安装的任何自定义工具都无法访问（默认情况下））。
构建工具会自动检测所有依赖项并将它们与您的应用程序一起部署（放入同一目录（或应用程序目录中的符号链接））并相应地设置路径。构建系统也可以以完全相同的方式解密到另一个开发人员的桌面或测试或生产，只需要几个额外的参数。
我工作过的另一家公司确实使用过虚拟机
我没有发现那种环境舒服。问题在于，虽然理论上虚拟机是生产环境的精确复制品，但只是在出现问题时更难以诊断。
- 这里的问题是，因为虚拟机是测试环境，公司认为开发盒不需要达到与prod机器相同的规格或需要相同的操作系统（错误一：你现在可以在dev中可靠地调试。
- 我们开发的工具安装在我们的机器上，当事情确实出错时通常非常有用。我们安装它们然后我们可以在出现问题时快速配置和使用它们。如果您使用的是虚拟机（即prod的副本），则需要将所有额外工具作为安装程序保存，然后进入并开始在虚拟机上安装所有这些额外工具（这既费时又费时）。
- 注意：您的构建系统必须能够在本地部署您的代码，因此默认情况下它不受您的工具的影响。您需要能够将这些插入正在运行的系统中。
- 我一直认为虚拟机只是一张可以启动的图像。
- 我不知道为什么这个构建系统花了这么长时间，但是花了45分钟来配置虚拟机并设置适当的环境（现在我不知道为什么我从未调查过它（我们有一个构建和测试团队他们正在看着它，所以我也离开了它们））。
- 由于不断的安全补丁，虚拟机图像往往偏离生产机器（并不准确）。
- 在公司A中，dev / test / prod同时获得了相同的补丁。注意：安全补丁不是自动的。所有补丁必须由生产和构建团队进行验证，以确保它们不会对生产系统产生负面影响。但是一旦确定，补丁就会自动应用于所有系统。
- 在公司B虚拟机映像未运行时，安全补丁不会自动应用。事实证明，需要共同努力来构建一个全新的虚拟映像（我希望这是自动化的（我认为它可以吗？））因此，即使安全补丁应用于prod / dev，它们也不会自动应用于虚拟图像。因此，虚拟图像每六个月才与生产重新同步。