改善我们的部署策略
我们有一个在公司开发的电子商务应用程序。它是我们开发和运行大约3年的合理标准的LAMP应用程序。我们在测试域上开发应用程序，在这里我们添加了新功能并修复了错误等。我们的错误跟踪和功能开发都在托管的Subversion解决方案（unfuddle.com）中进行管理。当报告了错误时，我们在测试域上进行了这些修复，然后在满意的情况下将更改提交到svn。我们遵循相同的步骤，但增加了新功能。 值得指出的是我们的系统和跨服务器的应用程序的一般体系结构。每次开发新功能时，我们都会使用我们的应用程序（始终由我们控制服务器）将此更新发布到所有站点。使用我们系统的每个站点基本上都使用完全相同的文件来获取95％的代码库。每个站点中都有几个文件夹，其中包含该站点定制的文件-css文件/图像等。除了每个站点之间的差异之外，每个站点之间的差异是由每个站点数据库中的各种配置设置定义的。 这涉及到实际的部署本身。当我们准备推出某种更新时，我们会在测试站点所在的服务器上运行命令。这将执行复制命令（cp -fru / testsite / / othersite /），并通过每个vhost强制根据修改后的日期更新文件。我们托管的每个其他服务器都有一个虚拟主机，我们将生产代码库同步到该虚拟主机，然后在该服务器上的所有站点上重复复制过程。在此过程中，我们将不想覆盖的文件移出，在复制完成后将它们移回。我们的发布脚本执行许多其他功能，例如应用SQL命令更改每个数据库，添加字段/新表等。 我们越来越担心我们的过程不够稳定，不能容错并且还有些蛮力。我们也意识到我们没有充分利用Subversion，因为我们有一种立场，即使用新功能会阻止我们推出重要的错误修复程序，因为我们没有使用分支或标签。我们在服务器之间进行了如此多的文件复制，这似乎也是错误的。我们也无法轻松地对刚刚推出的内容进行回滚。我们确实在每次推出之前都执行了diff操作，因此我们可以获得将要更改的文件的列表，因此我们知道之后所做的更改，但是回滚的过程仍然存在问题。在数据库方面，我已经开始研究dbdeploy作为潜在的解决方案。不过，我们真正想要的是有关如何改善文件管理和部署的一些常规指导。理想情况下，我们希望文件管理更紧密地链接到我们的存储库，以便将首次推出/回滚与svn连接起来。类似于使用export命令来确保站点文件与回购文件相同。但是，如果该解决方案也可以停止我们服务器周围的文件复制，那也很好。 忽略我们当前的方法，听到其他人如何解决相同的问题真的很好。 总结... 使多台服务器中的文件与svn保持同步的最佳方法是什么？ 我们应该如何防止文件复制？符号链接/其他？ 我们应该如何构造我们的仓库，以便我们可以开发新功能并修复旧功能？ 我们应该如何触发部署/回滚？ 提前致谢 编辑： 最近，我读到了很多关于将Phing和Capistrano用于此类任务的好东西。任何人都可以提供有关它们的更多信息以及它们在这种任务中的表现如何？