deployment - 部署大型系统有哪些常规做法？

Question

给定一个大型软件项目，其中包含用不同语言编写的多个组件，配置文件，配置脚本，环境设置和数据库迁移脚本-部署到生产环境的常见做法是什么？

有哪些困难要考虑？可以使用Ant或Maven之类的工具简化该过程吗？如何处理回滚和数据库管理？是否建议在生产环境中使用版本控制？

Answer 1

正如我所看到的，您主要是在询问release engineering AKA相关的最佳做法和工具-了解主题的“专业术语”很重要，因为它使查找更多信息变得更加容易。

在当今的软件开发中，必不可少的是配置管理系统（CMS，又称修订控制系统或版本控制系统）。如果您使用一个或多个IDE，则它们与CMS之间具有良好的集成也很不错，尽管对于开发目的而言，而不是出于部署/依赖的目的，这更是一个问题。

从一个不相关的观点来看，CMS的关键在于它必须对“分支”（使用任何名称）都具有良好的支持，因为发布必须从“发布分支”进行，在该分支中所有正在开发的代码及其所有依赖项（代码和数据）位于稳定的“快照”中，可以随意复制精确，相同的配置。

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

实际上，您可以通过创建一个发布分支来开始发布过程。然后，您需要在该分支上进行详尽的测试（通常比连续构建中每天要进行的测试要多得多-包括广泛的回归测试，集成测试，负载测试，性能验证等，并且可能还要花费更高的质量保证流程，具体取决于）。如果详尽的测试和质量检查发现发布候选版本中存在缺陷（包括回归，性能下降等），则必须予以修复；在大型团队中，在进行质量检查时，可能需要继续进行头部/树干的开发，因此需要轻松进行樱桃采摘/合并等操作（无论您是在头部还是在发布分支上进行修复，它仍然需要合并到另一端；-)。

最后但并非最不重要的一点是，除非您以某种方式跟踪CMS发行版所依赖的“所有内容”，否则您不会从CMS获得全部相关的价值-最简单的方法是拥有该工具的所有二进制文件的副本或硬链接您需要构建发行版等，但这通常不切实际；因此至少要跟踪使用的那些工具（操作系统，编译器，系统库，将图像，声音或视频文件预处理为最终形式的工具等）的确切版本，版本，错误修正和c编号。关键是在需要时能够准确地重现所需的环境，以重建建议发布的确切版本（否则，您会发疯地追踪细微的错误，这些错误可能取决于第三方工具的版本更改；- ）。

继CMS之后，第二个最重要的相关工具是良好的问题跟踪系统-理想情况下，它已与CMS很好地集成在一起。这对于开发流程（以及产品管理的其他方面）也很重要，但是就发布流程而言，问题跟踪工具的重要性在于能够轻松准确地准确记录已修复的错误，已添加的功能，已删除的功能，或更改，以及预期在新的即将发布的版本中对性能（或其他用户可观察到的特性）进行哪些修改。为此，开发中的一个关键“最佳实践”是，提交给CMS的每个变更集都必须与问题跟踪系统中的一个（或多个）问题相关联：毕竟，该更改必须有一定的目的（修复应该对软件用户不可见的错误，更改功能，优化某些内容或进行内部重构）；同样，每个标记为“已关闭”的跟踪问题都必须与一个（或多个）变更集相关联（除非关闭属于“无法修复/按预期工作”类型；与第三方组件中的错误＆c有关的问题如果您确实也要跟踪CMS中的所有第三方组件，则由第三方供应商修复的，很容易类似地处理，请参见上文；否则，至少应该有文字CMS下的文件记录了第三方组件及其演化，再次参见上文，当第三方组件上的某些跟踪问题被关闭时，需要对其进行更改）。

自动化各种相关的流程（包括构建，自动化测试和部署任务）是第三要务-自动化流程比要求某些贫困人员手动执行一系列步骤（对于足够复杂的任务，当然，自动化的工作流程可能需要“使人陷入困境”）。当您猜测时，诸如Ant（和SCons等）的工具可以在这里提供帮助，但是不可避免的（除非您很幸运地摆脱了非常简单直接的过程），您会发现自己在丰富它们使用即席脚本＆c（一些强大而灵活的脚本语言，如perl，python，ruby和＆c会有所帮助）。当您的发布工作流程足够复杂时（例如，涉及特定的人员或团队，在质量保证合规性，法律合规性，UI准则合规性等方面“签名”），“工作流引擎”也可能很宝贵。

您要询问的其他一些特定问题因环境的不同而有很大差异。如果您可以承受程序性的停机时间，那么即使使用大型数据库，您的生活也相对容易，因为您可以按顺序确定性地进行操作：请妥善关闭现有系统，确保保存并备份了当前数据库（减少了回滚， （在非常罕见的情况下是需要的），运行用于模式迁移或其他“不可逆”环境更改的一次性脚本，以普通用户仍然无法访问的模式再次触发系统备份，运行另一套广泛的自动化测试套件-最后，如果一切进展顺利（包括在新状态下保存和备份数据库，如果有的话），系统将再次开放供一般使用。

如果您需要在不停机的情况下更新“实时”系统，则范围可能从轻微的不便到系统的噩梦。在最佳情况下，事务是相当短的，事务设置的状态之间的同步可能会稍有延迟而不会造成损坏……并且您拥有相当多的资源（CPU，存储设备和c）。在这种情况下，您要并行运行两个系统-旧的和新的-并确保所有新事务都针对新系统，同时让旧事务在旧系统上完成。随着旧系统上的事务终止，一个单独的任务会定期将“旧系统中的新数据”同步到新系统。最终，您可以确定旧系统上没有正在运行的事务，并且在那里发生的所有更改都已同步到新的事务上–那时您可以最终关闭旧系统。 （当然，您也需要准备“反向同步”，以防需要回滚更改）。

这是实时系统更新的“简单，甜蜜”的极端。在另一个极端，您会发现自己处于一种过度约束的情况，以致无法证明该任务是不可能的（您不能用给定的资源在逻辑上满足所有规定的要求）。在旧系统上打开的长时间会话无法终止-稀缺的资源使无法并行运行两个系统-每个事务的硬实时同步的核心要求-等等，这些都可以使您生活惨淡（正如我所注意到的那样，极端情况下，使所陈述的任务绝对不可能）。您可以执行以下两项最佳操作：（1）确保您拥有足够的资源（当某些服务器意外崩溃时，这还将节省您的皮肤...您将需要另外一台服务器来应对紧急情况！ -）; （2）在最初定义整个系统的架构时，请从一开始就考虑这一困境（例如：相对于无法从快照中无缝快照，关闭和重新启动的长期会话，更喜欢短期事务“，是一种好的建筑指针；-)。