许多软件公司吹嘘他们已经将新功能快速增量发布到生产环境中。在我在大型 X 公司的后端项目中，我们有大版本（每季度发布 1 个）。我们使用 Scrum 进行为期 2 周的冲刺和系统集成测试，这是在发布到生产之前在相邻团队和客户之间完成的最后阶段（他们有自己的测试包）。我们的团队仅对我们的后端服务（分别为我们的测试包）使用与夜间回归测试的持续集成。我们还使用 Jira、git、nexus、stash 等现代敏捷工具进行代码审查、spock、junit 和 teamcity。
由于这些团队很忙，我们无法承受团队之间频繁的集成测试。我们由 QA 开发人员编写的回归测试最多需要约 10 小时（针对具有 terabutes 数据的数据库检查了许多功能）。对于拥有数百名消费者和 24/6 全天候工作的业务而言，我们所有的后端服务都至关重要。为了投入生产，我们所有的消费者也必须运行他们的集成测试。这需要大量的协调和时间。我们总是在周末的非工作时间发布。
因此，快速发布非常冒险且耗时。我想听听成功案例以及如何实现快速发布？这真的可行吗？
总结一下我的意见。说“快速 [频繁] 发布非常冒险且耗时”是不合逻辑的。
进行较小的版本可以降低测试这些版本的难度。如果您更频繁地发布，您的发布大小会减少，更改的功能数量会更少。
参见：Martin Fowler 的 FrequencyReducesDifficulty
在某种程度上，小版本与大版本的风险取决于您系统的架构。如果你有一个纠结的单体，那么影响不相关组件的更改的风险很高。为了解决这个问题，您需要分解组件，使它们彼此更加隔离。
如果您的架构是松耦合的，那么组件之间的连接就会更少。因此，每个组件都应该更容易单独测试。发布只能针对某些组件——您不需要每次都部署所有内容。
您还可以设计以使发布更容易。例如，如果您有一个高可用性系统，您可以同时运行旧版本和新版本，然后关闭旧版本并允许发生故障转移。
你不必在一次大爆炸中释放所有东西。您可以逐步推出，无论是按地区还是特定用户集。
API 应该有一个合同。这不仅仅是功能；线格式和行为。只要您知道所有服务都遵守该合同，那么它们就应该起作用。好的自动化测试应该会有所帮助。同样，考虑将大型 API 分解为更小的 API。
要说，“问题是这种方法在很多公司都行不通”也是值得怀疑的。我见过的最大障碍是文化障碍。人们不想改变，而且过程是根深蒂固的。
要频繁发布，您不必解决所有问题。您可以开始为新功能和服务做这件事。如果你不开始，它永远不会发生。
补充戴夫的答案：您根据交付成本进行推理，但这有点误导。
实际上重要的是“失败”交付的成本：由于交付是复杂/冗长/令人费解的，您当然希望尽可能少地这样做（并且尽可能少地失败）。这是一种可能的方法。为了做到这一点，您希望最大限度地减少错误的数量，因为发布补丁会变得冗长且昂贵。
另一种可能的方法是使其更易于部署，以便您可以更频繁地进行部署。一旦部署是一键式的，那么您就会意识到失败的成本变得很低。这样做的原因是错误的成本很低——您可以修复并单击部署。这反过来（通常）允许您减少发货前的测试量。
令人惊讶的是，根据个人经验，您最终可能会注意到，由于专注的额外好处，大多数错误无论如何都会被尽早发现 - 立即开发和发布。此外，还有另一类缺陷，在大爆炸系统中通常甚至不会考虑那么多：规范中的错误。换句话说，如果你构建了错误的东西，这通常是非常昂贵的——持续交付不是这样：便宜的运输意味着便宜的改变。
自动化
更快和更早的反馈
您的最终目标可能是每周发布，但首先要从每月发布。并且每小时进行一次回归测试。