我即将开始开发一个Web应用程序。 它将在云计算的专用服务器上运行。 目前我的开发环境是我的共享主机帐户。 我假设由于其严格的定制，限制和预期的目的（服务数百个站点而不是一个），模拟共享主机types的环境会更困难（也毫无意义）。
考虑到我将完全/根控制生产服务器，是否应该在物理或虚拟服务器上设置我的开发环境？ 如果是这样，我是否简单地将我的VirtualBox / VMware虚拟开发机器（或P2V）转换/映像/导入云中的虚拟机，或者我必须手动模拟环境（即安装相同的操作系统，软件，库，组件，补丁等）的开发机（和复制/ SVN的网站和DB）？ 如果没有，那么设置开发服务器以实现简单的实时转换的最佳做法是什么？
使用您的共享帐户进行开发工作可能是最糟糕的方式，因为它不太可能与最终的在线服务器相同的configuration。 我build议设置一个本地机器，以尽可能接近最终目标configuration的克隆。 关于物理与虚拟，如果虚拟提供了足够的性能满足您的需求，没有理由去实体。
如果您创build了目标计算机的本地克隆，那么到时候它实际上只是将文件复制过来，确保在目标上正确设置权限。 然后做一个数据库转储并加载到目标上。 这并不容易。
首先，保持运行日志中的任何修改，你做你的服务器，这就是所谓的Runbook 。 有些事情要手动logging：
其次，使用脚本来定义所有的环境variables和系统设置。 如果没有这个，至less要记下笔记。
第三，尽可能多的（如果不是所有的话）在版本控制之下，包括你的runbook和环境脚本。 你应该能够从你的SVN仓库部署一个新的服务器实例。
第四，保持备份，保持真的很好的备份。 testing他们。
其余部分对于您的部署非常具体。 在虚拟或物理服务器上进行设置完全取决于networking，磁盘和内存中的IO（input/输出）负载。 这只能随着时间的推移来量化，所以尽可能多的图表。
最重要的是，使事物模块化和可重复。
（感谢@bittrance的评论！）
这里有一些“使用脚本来设置你的环境variables”的例子。
假设我们正在谈论生产环境（而不是Google App Engine）的整个机器（无论是物理的还是虚拟的），我的最佳做法是：
花费额外的努力为您的软件创build适当的包装。 例如，针对RedHat的Java开发，使用/编写创buildRPM的Maven工具。 对于您的数据库，进行所有更改并将它们包含在RPM中，并让它们自动应用或创build一个适用于您的小工具。 本质上，当一个服务器可以用一个命令安装/升级时，你就完成了。 是的，这意味着包括为该系统定制的configuration文件。
这是一个额外的工作，但从长远来看这是非常值得的。
一旦你正确地打包了你的软件，dev / staging / demo服务器的问题就不再那么重要了，因为你总是可以build立另一个。 通过正确的安装程序，您确切知道需要对机器进行哪些更改才能正常工作。
不要担心迁移虚拟机：无论如何，您需要在迁移时更改大量的configuration参数。
如果你告诉我们更多关于OS / dev工具的信息，我可能会给你一些更具体的提示。
编辑：PHP / MySQL。 假设这是LAMP。
用您的PHP代码创build一个deb / rpm，这取决于您需要的各种Apache，mysql，mod_ssl，php包。 查看该平台上的其他PHP应用程序包以获取灵感。 通常情况下，您不希望在数据库上存在程序包依赖关系，因为数据库可能位于不同的方框中。
你的软件包应该包含两个SQL脚本（来自你的源代码仓库）：初始化一个新的数据库，包括授权语句，加载存储过程，创build索引等，以及加载一些可用于testing系统的演示数据快速起床并运行。 此外，您的软件包的后续版本可能包含升级数据库的修补程序脚本。
大多数现代Linux发行版都不愿意覆盖其他软件包的文件，所以尽可能避免使用它。
编辑2：如何从目录树build立一个Debian软件包。
你需要一个目录树，看起来像你想要做的安装（可以说在一个叫做构build的目录），你需要一些控制文件：
控制文件/控制：
Package: coolapp Version: 1.0.0-2 Architecture: i386 Maintainer: Skunkworks Dept <[email protected]> Depends: apache2 (>= 2.2.16) Section: contrib/libs Priority: optional Description: My Cool App It's going to revolutionize, yo! 控制文件/那些默认configuration文件：
etc/coolapp/settings.conf
鉴于这两个，使用这个脚本称为mkdeb：
#!/bin/bash CONTROLDIR=$1 shift SOURCEDIR=$1 shift INCLUDES=$* BUILD=/var/tmp/mkdeb CONTROLFILE=$CONTROLDIR/control PKGNAME=$(grep -E '^Package:' $CONTROLFILE | awk '{ print $2 }') PKGVERSION=$(grep -E '^Version:' $CONTROLFILE | awk '{ print $2 }') PKGARCH=$(grep -E '^Architecture:' $CONTROLFILE | awk '{ print $2 }') FILENAME=$PWD/${PKGNAME}_${PKGVERSION}_${PKGARCH}.deb rm -rf $BUILD && install -d $BUILD tar -C $SOURCEDIR -zcf $BUILD/data.tar.gz $INCLUDES # Proper debian packages have md5 sums for all their files (cd $SOURCEDIR && find $INCLUDES -type f | xargs md5sum > $BUILD/md5sums) metadata= for f in control prerm postrm preinst postinst templates conffiles ; do if [ -f $CONTROLDIR/$f ] ; then cp $CONTROLDIR/$f $BUILD chmod a+x $BUILD/$f metadata="$metadata $f" fi done # Metadata and stuff tar -C $BUILD -zcf $BUILD/control.tar.gz md5sums $metadata echo 2.0 > $BUILD/debian-binary (cd $BUILD && ar rc $FILENAME debian-binary control.tar.gz data.tar.gz)
像这样：
mkdeb ./controlfiles ./build .
保持开发的底层发行和生活一样。 例如，如果live是Ubuntu 10.10的ec2实例，那么dev应该是一个ubuntu 10.10环境，即使这意味着在你的（mac）笔记本电脑上运行一个虚拟机。 更好的是让它和现场一样，甚至使networking连接问题得到平衡。
使用configurationpipe理（puppet / chef）工具configuration这两个服务器/环境，使其自我logging和可重现。 在单台服务器上，这些工作同样如此简单。 你可以用一个只有一些if-dev / else-live黑客的巨大配方来简单地开始愚蠢的行为。 将这些配方与您的代码一起保存在您的版本控制系统中。
保持你的代码在版本控制的不同位置，可以像本地的trac / svnserve设置，或者可以像github一样托pipe。 只是分开，在某种程度上根本不涉及最终用户服务。 编写一个非常简单的脚本来从该版本控制系统部署您的应用程序。 它可以只是一个3或4行bash混合在一起的shell脚本，从简单的开始，保持在版本控制本身，并根据需要进行迭代。
如果你这样做，你将拥有一个与现场环境相匹配的开发环境，你可以用diff来certificate它。 您还可以获得一个简单的部署工作stream程，使您可以轻松快速地进行迭代，并且可以完成所有的基础工作，以构build匹配的服务器，并在需要时进行扩展。