我们公司开发了一款电子商务应用。这是一款相当标准的 LAMP 应用，我们断断续续开发了大约 3 年。我们在测试域上开发该应用，在这里我们添加新功能并修复错误等。我们的错误跟踪和功能开发全部在托管的 subversion 解决方案 (unfuddle.com) 中进行管理。报告错误后，我们会在测试域上进行修复，然后在我们满意错误已修复时将更改提交给 svn。我们在添加新功能时遵循相同的程序。
值得一提的是，我们的系统和应用程序在我们的服务器上的总体架构。每次开发新功能时，我们都会将此更新推广到使用我们应用程序的所有站点（始终是我们控制的服务器）。使用我们系统的每个站点基本上都使用完全相同的文件作为 95% 的代码库。我们在每个站点中都有几个文件夹，其中包含针对该站点定制的文件 - css 文件/图像等。除此之外，每个站点之间的差异由每个站点数据库中的各种配置设置定义。
这涉及到实际部署本身。当我们准备好推出某种更新时，我们会在测试站点所在的服务器上运行一个命令。这将执行复制命令 (cp -fru /testsite/ /othersite/) 并遍历每个 vhost 强制根据修改日期更新文件。我们托管的每个附加服务器都有一个 vhost，我们将生产代码库 rsync 到该 vhost，然后我们在该服务器上的所有站点上重复复制过程。在此过程中，我们移出我们不想覆盖的文件，并在复制完成后将它们移回。我们的推出脚本执行许多其他功能，例如应用 SQL 命令来更改每个数据库、添加字段/新表等。
我们越来越担心我们的流程不够稳定、不具备容错能力，而且有点暴力破解。我们还意识到我们没有充分利用 subversion，因为我们处于一个位置，开发新功能会阻止我们推出重要的错误修复，因为我们没有使用分支或标签。我们的服务器上有如此多的文件复制，这似乎也是不对的。我们也无法轻松地对刚刚推出的内容执行回滚。我们在每次推出之前都会执行 diff，这样我们就可以得到一个将要更改的文件列表，这样我们就知道之后发生了什么变化，但回滚的过程仍然有问题。在数据库方面，我已经开始研究 dbdeploy 作为一种潜在的解决方案。但我们真正想要的是一些关于如何改进文件管理和部署的一般指导。理想情况下，我们希望文件管理与我们的存储库更紧密地联系在一起，这样推出/回滚将与 svn 更紧密地联系在一起。比如使用导出命令来确保站点文件与存储库文件相同。如果解决方案可以停止我们服务器周围的文件复制，那就更好了。
忽略我们当前的方法，听听其他人如何处理同样的问题确实是件好事。
总结一下...
- 使多个服务器上的文件与 svn 保持同步的最佳方法是什么？
- 我们应该如何防止文件复制？符号链接/其他什么？
- 我们应该如何构建我们的 repo，以便我们可以开发新功能并修复旧功能？
- 我们应该如何触发推出/回滚？
提前致谢
编辑：
答案1
我对于发布版本的建议是，发布功能版本和维护版本。功能版本是包含新功能的版本。这些版本会添加到您的 Subversion 主干中。当您认为这些功能已完成时，您会将它们分支到发布分支中。一旦您的 QA 流程对此版本感到满意，您就可以标记该版本并将代码部署到您的服务器。
现在，当你收到错误报告时，你可以将此修复提交到分支和将其移植到主干。当您对修复的错误数量感到满意时，您可以标记并部署维护版本。
重要的是，您拥有一个与开发分支分开的实时代码库分支（或能够通过了解实时修订来创建一个分支），这样您就可以将修复程序部署到实时代码中，而无需部署新功能或未经测试的代码。
我建议使用发行版的原生打包系统来部署新代码。如果您有一个包含所有代码库的软件包，您就会知道您的所有代码都已在某种原子操作中部署，您可以一目了然地看到安装了哪个版本，可以使用软件包校验和来验证您的代码库。回滚只是安装软件包的先前安装版本的情况。
我认为您在实施此操作时遇到的唯一障碍是，您似乎在一台服务器上为不同的客户运行了多个代码库副本。我会尝试安排您的代码，以便所有客户都运行相同的文件，而不使用副本。我不知道这对您来说有多容易，但减少您必须处理的副本数量将大大减少您的麻烦。
我假设您提到 LAMP 时，您正在使用 PHP 或其他脚本语言，这些语言不需要编译过程。这意味着您可能错过了一个称为持续集成的绝妙过程。这基本上意味着您的代码正在不断接受测试，以确保它仍然处于可发布状态。每次有人签入新代码时，一个进程都会接受它并运行构建和测试过程。对于编译语言，您通常会使用它来确保代码仍然编译。对于每种语言，您都应该抓住机会运行单元测试（您的代码在可测试单元中，不是吗？）和集成测试。对于网站，测试集成测试的一个好工具是 Selenium。在我们的 Java 构建中，我们还测量代码覆盖率和代码指标，以查看我们随着时间的推移进展如何。我们发现 Java 的最佳 CI 服务器是 Hudson，但 buildbot 之类的东西可能更适合其他语言。您可以使用 CI 服务器构建包。
答案2
我们开始使用 Puppet（Reductive Labs 的旗舰产品）。这是一个基于 Ruby 的框架，用于自动化系统管理工作。几周前我参加了 puppetcamp，以下是视频链接：
此外，如果您想查看在旧金山 puppetcamp 上进行的所有演示，请访问以下链接：
享受。