最近我开始阅读有关使用虚拟化软件构建开发环境的信息（我是初学者），似乎'基础架构作为代码'是一个非常强大的概念。
我非常喜欢here所描述的工作流程结构：
但是，我仍然不太明白如何在生产服务器上传输和部署代码。
据我所知，保持DEV和PROD环境相同的常用方法是将Production服务器实例管理为另一个要使用Chef配置的虚拟映像。我可以在Production服务器上安装完全相同的操作系统，因为我（和团队）每天都使用VirtualBox-Vagrant-Chef。
但是生产服务器的硬件可能与虚拟客户操作系统中的硬件不同，这可能会再次导致不一致。
所以，问题是：
从使用VirtualBox-Vagrant-Chef工具链管理的开发环境向生产服务器传输和部署代码的已知和常见最佳做法是什么？这种做法是否允许任何持续部署？
[编辑]：注意：是否有任何在生产服务器上运行与Chef / Vagrant一起配置的VM实例的做法，如diagram所示？
答案 0 :(得分：22)
我是您关联的文章的作者，所以我的0.02
如果我正确理解了你的问题，你就不会将vms从开发转移到生产，你创建了一个可重复的过程，允许你一遍又一遍地创建相同的结束状态（OS + config + app），无论目的地在哪里。
通过使用vagrant，您可以保证您的开发人员使用与生产服务器相同的操作系统，无论他们使用哪种操作系统进行开发。
使用Puppet / Chef可以保证操作系统配置相同，无论它是在带有Vagrant的vm，生产中的虚拟机，云虚拟机还是裸机硬件中运行。它不需要是虚拟的。
答案 1 :(得分：1)
对于Puppet（Chef也很可能也这样做），你可以建立清单（配方），使它们在你的流浪环境中表现不同，例如。
if $::virtual != "virtualbox" { # not in vagrant
include sysctl_tuning
}
在这种背景下，关于持续交付的问题有点过于宽泛。我认为答案将是＆＃34;是＆＃34;，因为它的价值。