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