一般情况下，由多组件组成、多团队配合、依赖复杂的大型软件有3种版本发布方式

第一种是项目制发布模式：预先确定这个版本所需包含的特性集合；当版本的特性集合达到发布质量标准后，才能发布该版本，版本之间的时间间隔不确定，而是根据前一版本所有特性集合开发完成并达到发布标准所需时间进行评估确定的。其不足之处在于交付周期长，需求的变更极易引起延期交付，整体属于瀑布式研发模式，当前由于市场业务在快速变化，需要尽快上线，因此使用此种方式较少

第二种是版本火车方式：即事前制定关键的火车时刻计划，周期性的进行发布。相关需求需要在火车启动前满足“上车”条件，并在中途进行多层的质量或进展卡点检查需求进展状态（查票），如不满足要求即进行下车处理，以保障其它正常需求顺利到站下车。此模式有如下好处：1：统一的时间计划，使相关团队更具计划性、节奏感 2：固定周期的交付时间，可以保障每个月都会有新的功能发布，快速满足客户的部分需求 3：统一的版本及配套材料，方便于下流运维部署工作，有利于质量的保障

第三种是版本地铁方式：相较第二种火车方式，该方式不再要求“实名提前固定车次”，而是在有票（满足上车条件）情况下，随时就近上车（像地铁一样查票但不查车次），在车上完成相应的集成测试等环节，即可发布（到站下车），这种方式更灵活自由，发布频率可以更高，其重点在于前置条件的严格把控，不然会造成本版本及后续版本延期的连锁反应

综上，第三种是较为灵活的方式，如能配合Devops自动化工具进行部署、测试，可以做到较高的发版频率，不断满足快速迭代的业务需求