改善我们的部署策略

我们有一个在公司开发的电子商务应用程序。它是我们开发和运行大约3年的合理标准的LAMP应用程序。我们在测试域上开发应用程序，在这里我们添加了新功能并修复了错误等。我们的错误跟踪和功能开发都在托管的Subversion解决方案（unfuddle.com）中进行管理。当报告了错误时，我们在测试域上进行了这些修复，然后在满意的情况下将更改提交到svn。我们遵循相同的步骤，但增加了新功能。

值得指出的是我们的系统和跨服务器的应用程序的一般体系结构。每次开发新功能时，我们都会使用我们的应用程序（始终由我们控制服务器）将此更新发布到所有站点。使用我们系统的每个站点基本上都使用完全相同的文件来获取95％的代码库。每个站点中都有几个文件夹，其中包含该站点定制的文件-css文件/图像等。除了每个站点之间的差异之外，每个站点之间的差异是由每个站点数据库中的各种配置设置定义的。

这涉及到实际的部署本身。当我们准备推出某种更新时，我们会在测试站点所在的服务器上运行命令。这将执行复制命令（cp -fru / testsite / / othersite /），并通过每个vhost强制根据修改后的日期更新文件。我们托管的每个其他服务器都有一个虚拟主机，我们将生产代码库同步到该虚拟主机，然后在该服务器上的所有站点上重复复制过程。在此过程中，我们将不想覆盖的文件移出，在复制完成后将它们移回。我们的发布脚本执行许多其他功能，例如应用SQL命令更改每个数据库，添加字段/新表等。

我们越来越担心我们的过程不够稳定，不能容错并且还有些蛮力。我们也意识到我们没有充分利用Subversion，因为我们有一种立场，即使用新功能会阻止我们推出重要的错误修复程序，因为我们没有使用分支或标签。我们在服务器之间进行了如此多的文件复制，这似乎也是错误的。我们也无法轻松地对刚刚推出的内容进行回滚。我们确实在每次推出之前都执行了diff操作，因此我们可以获得将要更改的文件的列表，因此我们知道之后所做的更改，但是回滚的过程仍然存在问题。在数据库方面，我已经开始研究dbdeploy作为潜在的解决方案。不过，我们真正想要的是有关如何改善文件管理和部署的一些常规指导。理想情况下，我们希望文件管理更紧密地链接到我们的存储库，以便将首次推出/回滚与svn连接起来。类似于使用export命令来确保站点文件与回购文件相同。但是，如果该解决方案也可以停止我们服务器周围的文件复制，那也很好。

忽略我们当前的方法，听到其他人如何解决相同的问题真的很好。

总结...

• 使多台服务器中的文件与svn保持同步的最佳方法是什么？
• 我们应该如何防止文件复制？符号链接/其他？
• 我们应该如何构造我们的仓库，以便我们可以开发新功能并修复旧功能？
• 我们应该如何触发部署/回滚？

提前致谢

编辑：

最近，我读到了很多关于将Phing和Capistrano用于此类任务的好东西。任何人都可以提供有关它们的更多信息以及它们在这种任务中的表现如何？

我的建议是发布功能版本和维护版本。功能版本将是获得新功能的版本。这些被添加到您的Subversion干线中。当您认为这些功能已完成时，可以将其分支到发行分支。质量检查流程对此版本感到满意后，就可以标记该版本并将代码部署到服务器上。

现在，当您收到错误报告时，便将此修复提交到分支并将其移植到主干。当您对已修复的错误数量感到满意时，可以标记和部署维护版本。

重要的是，您必须拥有与开发分支分开的实时代码库分支（或具有通过了解实时修订版来创建分支的能力），以便能够将修补程序部署到实时代码中而不必部署新功能或未经测试的代码。

我建议您使用发行版的本机打包系统来部署新代码。如果您有一个包含所有代码库的软件包，那么您知道所有代码都已通过某种原子操作进行了部署，您可以一目了然地看到要安装的版本，可以使用软件包校验和来验证您的代码库。回滚只是安装软件包先前安装版本的一种情况。

我看到的实现此目标的唯一障碍是，您似乎拥有在同一台服务器上运行的不同客户的代码库的多个副本。我会尝试安排您的代码，以便所有客户都使用相同的文件，并且不使用副本。我不知道这对您来说有多容易，但是减少您必须处理的份数将大大减少您的头痛。

我假设就像您提到的LAMP一样，您使用的是PHP或另一种脚本语言，不需要编译过程。这意味着您可能错过了称为持续集成的出色过程。这基本上意味着要对您的代码进行不断测试，以确保其仍处于可发布状态。每次有人签入新代码时，就会有一个流程使用它并运行构建和测试过程。使用编译语言时，通常会使用它来确保代码仍在编译中。对于每种语言，您都应该趁机运行单元测试（您的代码位于可测试的单元中，不是吗？）和集成测试。对于网站而言，Selenium是测试集成测试的好工具。在我们的Java构建中，我们还测量代码覆盖率和代码指标，以了解随着时间的推移我们的进度。我们发现适用于Java的最佳CI服务器是Hudson，但是诸如buildbot之类的东西可能对其他语言更有效。您可以使用CI服务器来构建软件包。

我们开始使用Puppet（还原实验室的旗舰产品）。这是一个基于Ruby的框架，用于自动化sys-admin作业。几周前我在puppetcamp，这里是视频链接：

卢克·坎妮斯（Luke Kanies）演讲-木偶简介

另外，如果您想查看在旧金山的puppetcamp上所做的所有演示，请访问以下链接：

关于其他人如何使用Puppet的演示

请享用。