我们有一个在我们公司开发的电子商务应用程序。 它是一个合理的标准的LAMP应用程序，我们已经开发了大约3年。 我们在testing领域开发应用程序，在这里我们添加新的function和修复错误等。我们的错误跟踪和function开发全部在托pipe的颠覆解决scheme（unfuddle.com）内进行pipe理。 当错误被报告时，我们在testing域上做了这些修复，然后当我们很高兴错误已经修复时，将修改提交给svn。 我们按照相同的程序添加新的function。
值得指出的是我们的服务器系统和应用程序的总体架构。 每次开发新function时，我们都会使用我们的应用程序（始终是我们控制的服务器）将此更新推出到所有站点。 使用我们的系统的每个站点实际上使用95％的代码库完全相同的文件。 我们在每个站点内有几个文件夹，其中包含定制到该站点的文件–css文件/图像等。除此之外，每个站点之间的差异由每个站点数据库中的各种configuration设置定义。
这将开始实际部署本身。 当我们准备推出某种更新时，我们会在testing站点所在的服务器上运行一个命令。 这将执行复制命令（cp -fru / testsite / / othersite /），并通过每个基于修改date更新文件的vhost force。 我们托pipe的每个附加服务器都有一个虚拟主机，用于同步生产代码库，然后我们在该服务器上的所有站点上重复复制过程。 在这个过程中，我们移出不想被覆盖的文件，在完成复制时将其移回。 我们的推出脚本执行一些其他function，如应用SQL命令来改变每个数据库，添加字段/新表等。
我们越来越担心我们的过程不够稳定，不容错过，也是一种暴力方法。 我们也意识到，我们并没有充分利用颠覆，因为我们有一个职位，即在不使用分支或标签的情况下，开发新function将阻止我们推出重要的错误修复。 这似乎也是错误的，我们有这么多的文件复制我们的服务器。 我们也无法轻松地对我们刚推出的产品进行回滚。 我们在每次推出之前都会执行diff操作，以便我们可以获得将要更改的文件列表，以便我们知道之后发生了什么变化，但是回滚过程仍然存在问题。 就数据库而言，我已经开始关注dbdeploy作为一个潜在的解决scheme。 但是，我们真正想要的是关于如何改进文件pipe理和部署的一般性指导。 理想情况下，我们希望文件pipe理更紧密地连接到我们的存储库，所以卷展/回滚将更多地连接到SVN。 就像使用导出命令来确保站点文件与回购文件一样。 如果解决scheme也可能会停止我们的服务器周围的文件复制，这也是一件好事。
忽视我们目前的方法，听听其他人如何解决同样的问题真的很好。
总结…
提前致谢
编辑：
我最近读了很多关于使用Phing和Capistrano完成这些任务的好东西。 任何人都可以提供更多关于他们的信息，他们对于这样的任务有多好？
我对发布版本的build议是有function发布和维护版本。 function版本将是获得新function的版本。 这些被添加到你的颠覆主干。 当您认为这些function已完成时，可以将这些分支分支到发布分支中。 一旦您的QAstream程对此版本感到满意，您可以为该版本添加标签并将代码部署到您的服务器上。
现在，当您得到一个错误报告时，您将此修复提交到分支并将其移植到中继。 如果您对修复的错误数量感到满意，则可以标记和部署维护版本。
重要的是，您有一个与您的开发分支不同的实时代码库的分支（或者有能力通过了解实时版本创build一个分支），以便您能够将修订部署到您的实时代码，而无需部署新function或未经testing的代码。
我build议使用你的发行版的本地打包系统来部署新的代码。 如果你有一个包含你所有代码库的包，你知道你所有的代码都是以一种primefaces操作的forms部署的，你可以一目了然地看到安装的是哪个版本，可以使用包的校验和validation你的代码库。 回滚只是安装以前安装的软件包版本的情况。
我可以看到，实现这一目标的唯一障碍是，您似乎在一台服务器上运行不同客户的代码库有多个副本。 我会尝试安排您的代码，以便所有客户运行相同的文件，不使用副本。 我不知道这对你有多容易，但减less你需要处理的份数将大大减less你的头痛。
我假设，正如你提到的LAMP，你正在使用PHP或其他脚本语言，这不需要编译过程。 这意味着你可能错过了一个称为持续集成的美妙过程。 这基本上意味着你的代码不断被testing，以确保它仍然处于可释放状态。 每当有人检查新的代码时，一个进程就会接受并运行构build和testing过程。 用编译语言，你通常会使用这个来确保代码仍然被编译。 使用每种语言，您应该借此机会运行unit testing（您的代码是可testing的单元不是吗？）和集成testing。 对于网站来说，testing集成testing的好工具是Selenium。 在我们的Java构build中，我们还测量代码覆盖率和代码度量，以了解我们如何随着时间的推移而进步。 我们发现Java最好的CI服务器是Hudson，但是像buildbot这样的东西可能对其他语言更好。 您可以使用您的CI服务器来构build软件包。
我们开始使用Puppet（Reductive Labs的旗舰产品）。 这是一个基于Ruby的自动化系统pipe理作业的框架。 几周前我在傀儡馆，这里是video链接：
卢克Kanies介绍 – 木偶介绍
另外，如果你想看到在旧金山的傀儡营所做的所有演讲，这是链接：
关于其他人如何使用木偶的介绍
请享用。