改进我们的部署策略

Question

我们有一个在我们公司开发的电子商务应用程序。它是一个相当标准的 LAMP 应用程序，我们已经断断续续地开发了大约 3 年。我们在测试域上开发应用程序，在这里我们添加新功能并修复错误等。我们的错误跟踪和功能开发都在托管的颠覆解决方案 (unfuddle.com) 中进行管理。在报告错误时，我们会在测试域上进行这些修复，然后在我们对错误已修复感到满意时将更改提交到 svn。我们遵循相同的程序添加新功能。

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

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

我们越来越担心我们的流程不够稳定，不具备容错能力，也有点暴力方法。我们也意识到我们没有充分利用 subversion，因为我们有一个立场，即开发新功能会阻止我们推出重要的错误修复，因为我们没有使用分支或标签。我们在我们的服务器上有如此多的文件复制似乎也是错误的。我们也无法轻松地对我们刚刚推出的内容执行回滚。我们确实在每次推出之前执行差异，以便我们可以获得将要更改的文件列表，以便我们知道之后更改了什么，但回滚过程仍然存在问题。就数据库而言，我已经开始将 dbdeploy 作为一种潜在的解决方案。不过，我们真正想要的是关于如何改进文件管理和部署的一般指导。理想情况下，我们希望文件管理与我们的存储库更紧密地联系在一起，因此推出/回滚将更多地与 svn 相关联。类似于使用 export 命令来确保站点文件与 repo 文件相同。如果解决方案也可以停止我们服务器周围的文件复制，那也很好。

忽略我们目前的方法，听听其他人如何解决同样的问题会非常好。

总结...

• 使跨多个服务器的文件与 svn 保持同步的最佳方法是什么？
• 我们应该如何防止文件复制？符号链接/其他东西？
• 我们应该如何构建我们的 repo 以便我们可以开发新功能并修复旧功能？
• 我们应该如何触发推出/回滚？

提前致谢

编辑：

我最近阅读了很多关于使用Phing和Capistrano执行此类任务的好文章。任何人都可以提供更多关于他们的信息以及他们对这种任务的表现如何？

Answer 1

我对发布的建议是拥有功能发布和维护发布。功能发布将是获得新功能的发布。这些会被添加到你的 subversion 主干中。当您认为这些功能完成时，您将它们分支到发布分支中。一旦您的 QA 流程对该版本感到满意，您就可以标记该版本并将代码部署到您的服务器。

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

重要的是，您的实时代码库的一个分支（或能够通过了解实时修订来创建一个分支）与您的开发分支分开，以便您能够将修复程序部署到您的实时代码，而无需部署新功能或未经测试的代码。

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

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

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