在我看来，您主要是在询问 release engineeringAKA releng 的最佳实践和工具——了解某个主题的“艺术术语”很重要，因为这样可以更轻松地搜索更多内容信息。
配置管理系统（CMS——又名修订控制系统或版本控制系统）对于当今的软件开发来说是必不可少的；如果您使用一个或多个 IDE，最好在它们与 CMS 之间进行良好的集成，尽管这对于开发目的而言更多是一个问题，而不是出于部署 / releng 的目的。
从 releng 的角度来看，CMS 的关键在于它必须对“分支”（以任何名称）提供良好的支持，因为发布必须从一个“发布分支”进行，其中所有正在开发的代码和所有它的依赖项（代码和数据）都在一个稳定的“快照”中，可以随意复制精确、相同的配置。
如果您必须维护多个分支（针对不同用途、平台等进行定制），对良好分支支持的需求可能会更加明显，但即使您的发布始终严格地在一个线性顺序，releng 最佳实践仍然要求创建发布分支。 “良好的分支支持”包括易于合并（以及对文件进行不同更改时的“冲突解决”），“樱桃采摘”（从一个分支或头部/主干获取一个补丁或变更集，并将其应用于另一个分支），等等。
在实践中，您通过创建发布分支开始发布过程；然后，您在该分支上运行详尽的测试（通常比您在持续构建中每天运行的要多得多——包括广泛的回归测试、集成测试、负载测试、性能验证等，甚至可能更昂贵的质量保证过程，具体取决于)。如果详尽的测试和 QA 揭示了候选版本中的缺陷（包括回归、性能下降等），则必须修复它们；在一个大型团队中，在完成 QA 时，head/trunk 上的开发可能会继续进行，因此需要易于挑选 / 合并 / 等（无论您的实践是在 head 上还是在发布分支上执行修复，它仍然需要合并到另一边；-)。
最后但并非最不重要的一点是，除非您以某种方式跟踪您的发布所依赖的“一切”，否则您不会从您的 CMS 获得完整的 releng 价值——最简单的方法是拥有所有二进制文件的副本或硬链接用于构建发布等所需的工具，但这通常是不切实际的；因此，至少要跟踪所使用的那些工具（操作系统、编译器、系统库、将图像、声音或视频文件预处理为最终形式的工具等）的确切版本、版本、错误修复和 c 编号。关键是能够在需要时准确重现重建建议发布的确切版本所需的环境（否则你会发疯追踪可能依赖于第三方工具的细微错误'随着他们的版本的变化而变化；-)。
在 CMS 之后，releng 的第二个最重要的工具是一个很好的问题跟踪系统 - 最好是与 CMS 完美集成的系统。这对于开发过程（以及产品管理的其他方面）也很重要，但就发布过程而言，问题跟踪器的重要性在于能够轻松地准确记录已修复的错误、添加、删除的功能，或更改，以及在即将发布的新版本中预期性能（或其他用户可观察的特征）的哪些修改。为此，开发中的一个关键“最佳实践”是提交给 CMS 的每个变更集必须连接到问题跟踪系统中的一个（或多个）问题：毕竟，必须是该更改的一些目的（修复错误、更改功能、优化某些内容或一些本应对软件用户不可见的内部重构）；同样，每个标记为“已关闭”的跟踪问题都必须连接到一个（或多个）变更集（除非关闭是“无法修复/按预期工作”的类型；与第三方组件中的错误和 c 相关的问题已由第三方供应商修复，如果您确实设法跟踪 CMS 中的所有第三方组件，则很容易进行类似处理，请参见上文；如果您不这样做，至少应该有文本CMS 下记录第三方组件及其演变的文件，再次参见上文，当第三方组件上的某些跟踪问题关闭时需要更改这些文件。
自动化各种 releng 流程（包括构建、自动化测试和部署任务）是第三个首要任务——自动化流程比要求一些可怜的人手动完成一系列步骤（足够复杂的任务，当然，自动化的工作流程可能需要“让人类参与其中”）。正如您所猜测的，Ant（和SCons 等）之类的工具可以在这里提供帮助，但不可避免的是（除非您足够幸运能够摆脱非常简单直接的过程）您会发现自己丰富了它们使用临时脚本 &c（一些强大而灵活的脚本语言，例如 perl、python、ruby 和 &c 会有所帮助）。当您的发布工作流程足够复杂时（例如，涉及特定人员或其群体“签署”QA 合规性、法律合规性、UI 准则合规性等），“工作流程引擎”也很宝贵。
您询问的其他一些具体问题因环境的具体情况而有很大差异。如果您能负担得起程序化的停机时间，那么即使使用大型数据库，您的生活也会相对轻松，因为您可以按顺序和确定性地操作：您可以优雅地关闭现有系统，确保保存和备份当前数据库（轻松回滚，在极少数情况下需要它），运行用于架构迁移或其他“不可逆”环境更改的一次性脚本，以一般用户仍然无法访问的模式再次启动系统备份，运行另一套广泛的自动化测试-- 最后，如果一切顺利（包括在新状态下保存和备份数据库，如果相关），系统将再次开放供一般使用。
如果您需要在不停机的情况下更新“实时”系统，这可能是轻微的不便，也可能是系统性的噩梦。在最好的情况下，事务相当短，事务设置的状态之间的同步可能会延迟一点而不会造成损坏……并且您拥有合理丰富的资源（CPU、存储等）。在这种情况下，您并行运行两个系统——旧系统和新系统——并确保所有新事务都以新系统为目标，同时让旧系统在旧系统上完成。当旧系统上的事务终止时，一个单独的任务会定期将“旧系统中的新数据”同步到新系统。最终，您可以确定旧系统上没有任何事务正在运行，并且那里发生的所有更改都同步到新系统 - 那时您最终可以关闭旧系统。 （当然，您也需要准备好“反向同步”，以防需要回滚更改）。
这是实时系统更新的“简单，甜蜜”的极端；在另一个极端，您会发现自己处于过度约束的情况下，以至于您可以证明任务是不可能的（您只是无法在给定资源的情况下从逻辑上满足所有规定的要求）。在旧系统上打开的长时间会话无法终止——稀缺的资源使得无法并行运行两个系统——每个事务的硬实时同步的核心要求——等等，都可以让你生活很悲惨（正如我注意到的那样，极端情况下，可以使所陈述的任务绝对不可能）。你可以做的最好的两件事：（1）确保你有丰富的资源（当一些服务器意外崩溃时，这也可以节省你的皮肤......你将有另一个可以启动以应对紧急情况！ -); （2）从一开始就考虑这个困境，在最初定义整个系统的架构时（例如：更喜欢短期事务而不是不能从快照无缝地“快照、关闭和重新启动”的长期会话"，是一个很好的架构指针；-)。