Deployment 部署大规模系统的常见做法是什么？

考虑到一个大型软件项目，其中有几个用不同语言编写的组件、配置文件、配置脚本、环境设置和数据库迁移脚本，部署到生产环境的常见做法是什么

有什么困难需要考虑？可以使用Ant或Maven等工具简化流程吗？如何处理回滚和数据库管理？建议在生产环境中使用版本控制吗？

免责声明：在我工作的地方，我们使用的是我写的我将要提到的东西

我会告诉你我是怎么做的

对于配置设置以及代码和内容的常规部署，我使用NAnt、CI服务器和（自动部署工具）的组合。您可以将dashy替换为任何其他“东西”，从而自动上传到您的服务器（也许）

对于DB脚本，我们使用RedGate SQL Compare来获取脚本，然后对于大多数更改，我实际上会在适当的地方手动进行更改。这是因为有些变化有点复杂，我觉得用手做起来更舒服。实际上，您可以使用这个工具来完成这项工作（或者至少生成脚本）

根据您的语言，有一些工具可以为您编写DB更新脚本（我想这个论坛上有人写了一个，希望他会回复），但我没有使用这些工具的经验。不过我想补充一点

困难

我忘了回答你的一个问题

更新任何非常复杂/分布式站点的最大问题是数据库同步。你需要考虑是否有停机时间，如果你有，DBS将会发生什么。您是否会关闭所有内容，以便无法处理任何事务？或者您会将所有内容转移到一台服务器，更新DB B，然后同步DB A和B，然后更新DB B吗？还是别的什么

无论你选择什么，你都需要选择它，或者说“好的，每次更新都会有X次停机”，或者其他什么。把它记录下来就行了

---

你能做的最糟糕的事情就是让某人的事务在处理过程中失败，因为你正在更新服务器；或者以某种方式只保留系统的一部分运行。

我认为您在使用版本控制或不使用版本控制方面没有任何选择

如果没有版本控制（如注释中所述），您将无法运行

我是根据经验说话的，因为我目前在一个网站上工作，我们有几个项目必须一起工作：

• 软件本身及其在给定时间点的功能
• 与我们链接的外部系统（其中6个）（消息已版本化）
• 保存配置（和翻译）的数据库
• 托管在Apache服务器上的静态资源（图像、css、javascripts）（实际上有几个）
• java小程序，必须与javascript和软件同步

这是因为我们使用了版本控制，尽管我必须承认我们的数据库非常简单，而且部署是自动化的

版本控制意味着我们实际上在任何时候都有消息、数据库、静态资源和Javaapplet的多个并发版本

在发生“撤退”时，这一点尤为重要。如果你在加载新软件时发现了一个缺陷，突然间你负担不起加载，那么如果你没有进行版本控制，你将面临危机，如果你有，你将不得不加载旧软件

现在，正如我所说，部署是脚本化的： -首先部署静态资源（+java小程序） -接下来是数据库，几个配置共存，因为它们是版本化的 -软件在“凉爽”的时间窗口中排队等待加载（当我们的流量处于最低点时，所以在晚上）

---

当然，我们会处理与外部服务器的向后/向前兼容性问题，这一点不应低估。

在我看来，您主要是在询问AKA Reling的最佳实践和工具——了解主题的“艺术术语”很重要，因为它使搜索更多信息变得更容易

配置管理系统（CMS——又称版本控制系统或版本控制系统）是当今软件开发必不可少的；如果您使用一个或多个IDE，那么在它们和CMS之间进行良好的集成也是很好的，尽管这对于开发来说比部署/发布来说更重要

从发布的角度来看，CMS的关键在于它必须对“分支”（无论名称如何）有很好的支持，因为发布必须从“发布分支”进行，其中所有正在开发的代码及其所有依赖项（代码和数据）都位于一个稳定的“快照”中，从该快照中可以获得准确的，可以随意复制相同的配置

如果您必须维护多个分支（针对不同的用途、平台等进行定制），那么对良好分支支持的需求可能会更加明显，但即使您的发布始终严格按照单一线性顺序进行，发布最佳实践仍然要求创建发布分支。“良好的分支支持”包括易于合并（以及在对文件进行不同更改时的“冲突解决”）、“樱桃挑选”（从一个分支或头部/主干获取一个补丁或变更集，并将其应用于另一个分支）等

在实践中，您通过创建发布分支开始发布过程；然后，您在该分支上运行详尽的测试（通常比您在连续构建中每天运行的测试要多得多——包括广泛的回归测试、集成测试、负载测试、性能验证等，可能还包括更昂贵的质量保证过程，具体视情况而定）。如果以及何时详尽的测试和QA发现候选版本中存在缺陷（包括回归