现有的三种发布模式介绍

先说现有版本的发布模式，再谈火车模型。参照乔梁的连续交付2.0，从特点、时间、质量三个角度总结了三种发布模式：项目系统发布模式（ProjectRleaseMode）火车模式的传统版本（ReleaseTrainMode）城际快线模式（IntercityExpressMode）一、项目制发布模式项目制发布模式是指在某个版本的软件规划中，提前确定本版本所需的特征集合；当版本的特征集合达到发布质量标准时，版本之间的时间间隔不确定，但根据前一版本的所有特征集合开发并达到发布标准所需的时间进行评估。明显的优点是，您可以准确地知道每个版本包含哪些具体功能，这有利于商业套装软件的销售模式符。明显的优点是，您可以准确地知道每个版本包含哪些具体功能，这有利于商业套装软件的销售模式符号。缺点是项目整个交付周期长，参与者多，需求变化容易影响版本的交付时间。第二，火车模型发布模式“启示录:打造用户喜爱的产品”这里说的第一个是很多成熟的互联网公司都在使用火车模型发布模式。Firefox目前正在采用的发布过程实际上是火车模型的发布模式。从实现和进入mozila-central分支到发布到用户只需要12-18周的时间，而不需要几年的时间来更新IE浏览器。如此快速的发布过程给整个项目带来了更好的灵活性和更强的稳定性。在每个发布周期的测试和稳定阶段，更多的用户可以帮助FireFox开发人员更早地发现和解决问题，并对每个发布质量保持信心。以下是Firefox的发布过程，每个独立的发布列车（新的发布过程使用列车模型，固定的“启动”时间，特征的发布取决于特征是否赶上最近的列车启动时间），包括6周的开发时间和12周的稳定时间：新的开发结果不会直接发布到Aurora和Beta分支，开发人员和社区测试人员需要共同测试这些分支；如果在开发过程中发现程序问题或漏洞，则需要首先解决问题。如上图所示，发布周期基本稳定18周。Aurora和Beta分支基本上完全关注稳定性和测试，许多工程师同时开始新的开发工作；所以，如果你看到更大的图表，以下是一个真正的过程：在Aurora和Beta分支的12周内，Mozila开发社区并不闲置，他们将继续发布新的特征和bugfix。每六周，他们的工作将有选择地合并到Aurora分支，然后合并到Beta分支；观察上图，你会发现每六周有一个新版本是非常重要的。每六周，他们的工作将有选择地合并到Aurora分公司，然后合并到Beta分公司；观察上图，你会发现每六周有一个新版本是非常重要的。提前几个月制定发布火车的时间表，纯粹是为了给各业务和技术部门足够的时间进行预计，以便进行依赖和影响的相关评估。这种模式预计三个维度(时间、质量、特点)都能通过更长时间的预计划来满足预期。该模型的优点是，用户可以提前了解每个版本的重要特征和相应版本的发布时间，并提前体验最新产品版本提供的新特征；然后根据经验结果决定是否应用于自己的生产环境；即使你决定在自己的生产环境中使用这个版本，你也可以等到新版本成熟稳定。缺点是需要提前很长时间制定时间计划，制定发布计划的活动是一个非常正式和结构化的过程；需要一些格式化的数据，以确保参与发布列车的团队能够判断正式加入的可行性。这些数据包括:发布详细信息(相对标识、名称、部署日期、风险等级、发布类型-企业、计划或投资组合)；整个生命周期的各个阶段和预定日期如下图所示(Libreoffice5).列车4版时间表)显示；各阶段要完成的活动和任务；里程碑时间和质量要求；列车发布的主要负责人负责管理。三、城际快线模式（IntercityExpressMode）城际快线模式（IntercityExpressMode）是指根据发布时间点前已达到固定质量标准的特点，在发布策略的三个要素中选择固定的时间和质量维度，时间周期相对较短（如一周甚至一天）。它与传统的火车发布模式有两个区别：发布周期间隔短，通常在两周内；负责特色开发的团队可以选择乘坐哪条城际快线，而不需要提前很长时间确定。这种模式在提供互联网服务或SaaS服务的软件公司中很常见，其优点是降低了团队和角色之间的协调成本——因为每个人都知道每次发布的具体时间点，所有任务都可以根据这个时间点提前协调；即使特征没有赶上最新版本，他们也知道特征是否可以在下次发布时间点发布。例如，FacebookWeb主站的发布周期是每个工作日发布两次。这种城际快线模式的优点是每个人都知道每个时间点；每个人都感受到特征的进步；速度不断提高；更注重生产质量。当然也有缺点:未完成的代码会一起发布；每个人都有紧迫感；如果频率变慢，需要更多的时间来制定计划。那么，这样的发布火车间隔多长时间合适呢？当你不了解企业的具体情况时，这是一个很难回答的问题，但你仍然可以给出一些建议，即在不影响用户体验、不增加成本和合规性的前提下，尽可能缩短发布周期，让你感到有点紧张；例如，每月发布一个版本，现在你可以把两周作为目标（当然，这并不容易）。4、分支策略与版本发布模式之间的关系分支策略与版本发布之间存在着微妙的相关性。在项目系统发布模式下，研发团队采用的分支策略往往是主要的开发模式；在使用城际快线模式的团队中，也倾向于采用主要的开发模式。当发布周期在两者之间时，其分支策略通常倾向于“多分支开发、主要发布”模式（无论是特征分支还是团队分支）；当然，这不是绝对的，会有很大的重叠部分，通常会受到团队成员和产品结构的影响。项目系统的发布模式不会消失。毕竟，在完成第一个基本MVP之前，每个新产品都需要这样一个首次启动过程。目前，许多传统IT企业仍采用项目系统发布模式。然而，城际快线模式越来越流行，越来越多的企业开始使用这种城际快线模式。即使在当前版本发布周期较长的企业中，城际快线模式也经常应用于项目系统发布模式，即在项目周期中添加固定时间的迭代，并要求在每个迭代结束时获得可交付状态的产品——这里的可交付状态是指软件可以正常运行，已完成的软件特性符合发布质量标准，而不是商业发布。一般来说，当发布周期短到一定程度时，主要开发模式更具优势，因为分支开发模式的合并成本将成为城际快线发布模式的障碍。如果发布周期等于或短于两周，建议软件团队毫不犹豫地改进工作模式，转向“主要开发模式”。许多互联网公司选择城际快线模式。例如，Facebook主站在2010年之前就开始使用这种城际快线模式；2012年，每个工作日定期发布两次，其移动终端的发布节奏也从最初的项目系统发布模式转变为城际快线模式。谷歌的ChromePC版本也选择了城际快线模式，其Beta版本每周发布一次，而Stable版本每月发布一次。在国内公司中，2011年人民网也采用这种发布火车模式，每个工作日早上7点更新其网站。虽然项目系统的发布不会在短时间内消失，但城际快线模式可以作为软件交付团队能力的指示。