软件集成的分支策略

集成的分支策略

版本控制系统的使用目的

概述

• 版本控制系统（version control system）主要用于存储及追踪目录（文件夹）和文件的修订历史（修订操作包括3类：新增、修改、删除），能够回溯哪些被纳入其管理范围之内的任意对象的任意一次修订
• 本质上的作用是回答“4个W”，即在什么时间（When）、修改了什么内容（What）、是谁修改的（Who）、为什么要修改（Why）
• 目前市面上主流的版本管理系统被划分为集中式版本控制和分布式版本控制系统两类

分析

集中式版本控制系统

• 集中式版本控制系统都有一个单一的集中管理的版本控制管理服务器，保存所有的文件的历史修订版本记录
• 成员需要通过集中式版本控制系统的客户端才能与仓库中的内容进行交互
• 集中式版本控制系统会有流量瓶颈和单点故障的风险

分布式版本控制系统

• 分布式版本控制系统提交操作都是在本地进行而无须经过服务器，因此提交速度也更快
• 只有需要向其他人或远程服务器做文件提交或同步时，才通过网络将其推送到远程仓库或从远程仓库拉取
• 即使在没有网络环境的情况下，你也可以非常愉快地频繁提交更新。当有了网络环境的时候，再推送到远程的团队代码仓库
• 目前主流的分布式版本控制系统是Git

版本控制系统中的基本概念

• 代码仓库（codebase）。是指一个包含一组文件所有历史修改信息的逻辑单位，通常用于保存有关一个软件产品或某一组件的所有文件信息记录
• 分支（branch）。指对选定的代码基线创建一个副本。可以对这个副本中的文件进行操作，而这些操作与原有代码基线的文件操作是互不影响的
• 主干（trunk/master）。是一个具有特殊意义的分支，通常在创建代码仓库时即由版本控制系统默认创建，每个代码仓库有且仅有一个这样的分支。该分支与与软件开发活动和发布方式紧密关联
• 版本号（reversion）。对应在某个分支上的一次提交操作，是系统产生的一个编号。通过该编号，可以获取此次提交操作时的所有文件镜像
• 标签（tag）。指某个分支上某个具体版本号的一个别名，以方便记忆与查找。可以通过版本控制工具自身提供的命令来创建这个别名
• 头（head）。指某个分支上的最新一次提交对应的版本号
• 合入（merge）。指将一个分支上的所有内容与某个目标分支上的所有内容进行合并，并在该分支上创建一个新版本号
• 冲突（conflict）。指在合入操作时，两个分支上的同一个文件在相同位置出现不一致的内容。通常需要人工介入，确认如何修改后，方可合入目标分支

代码镜像路径完整格式

• ｛代码仓库名｝：｛分支名｝：｛版本号｝或者｛代码仓库名｝：｛分支名｝：｛标签｝

分支开发

开发模式

主干开发，主干发布（Trunk-based Development & Release）

• 该模式指工程师向主干上提交代码（或每个分支的生命周期很短，如数小时，或少于一天），并用主干代码进行软件交付
• 所有特性的开发，代码均提交到主干上；当需要发布新功能时，直接将主干上的代码部署到生产环境上
• 根据交付频率可分为低频交付和高频交付两类。低频交付常用于一些周期比较长的大型软件开发项目，版本控制系统的作用仅仅是确保代码不丢失，是纯粹的代码备份仓库；高频交付是指代码仓库中的代码发布频率较高，通常每天都会发布一次或多次，高频交付常用于具有比较完备的交付基础设施（自动化构建、自动化测试、自动化运维、自动化监控、自动化监控与报警等）的互联网团队，通常也有较快速缺陷修复能力，尤其适用于后台服务端产品形态。例如Web网站或SaaS软件后台服务
  这种模式的分支方式简单，分支管理工作量较少（如代码合并成本）。但由于频繁提交代码，其代码变动非常快，容易导致自己这个分支上的代码较难合并回去

主干开发，分支发布（Trunk-based Development & Branch-based Release）

• 这种模式是指开发人员将写好的代码提交到主干；当新版本的功能全部开发完成或者已经接近版本发布时间点的时候，从主干上拉出一个新的分支；在这个新的分支上进行集成测试，并修复缺陷，进行版本质量打磨，当质量达标后，再对外发布版本
• 其特点包括主干代码提交活动频繁，对保障主干代码质量有较大的挑战；分支只修复缺陷，不增加新功能；新版本发布后，如果发现严重缺陷，而且必须立即修复的话，只要在该版本所属的分支上修复后，再次发布补丁版本，然后将分支上的修改合并回主干即可
• 该模式发布分支的生命周期不宜持续时间过长，一段时间后应该终止该分支上的任何操作
• 该模式下，从拉出分支开始，到分支代码达到可交付的时间周期可以作为评估主干代码质量的指示器，也称为“质量打磨周期”
• 该模式下，与将要发布的新功能无关的人员可以持续工作在开发主干上，不受版本发布的影响，新发布的版本出现缺陷后，可以直接在新版本发布分支上进行修复，主干上可以并行开发新功能代码通常只能针对下一个新发布版本的功能开发，当有新发布版本的任何功能未开发完成，就不能创建版本发布分支，否则会影响下一个发布的开发计划。需要对发布分支的数量加以约束。如果分支周期较长，很容易出现“分支地狱”倾向
• 这种模式常用于“系列化产品簇+个性化定制”的项目。例如某硬件设备的软件产品研发的分支模式

分支开发，主干发布（Branch-based Development & Trunk-based Release）

• 该模式是指团队从主干上拉出分支，并在分支上开发软件新功能或修复缺陷；当某个分支（或多个分支）上的功能开发完成后，要对外发布版本时，才合入主干；通常在主干上进行缺陷修复，质量达标后，再将主干上的代码打包发布
• 这种模式在分支合并之前，每个分支之间的开发活动互相不受影响；团队可以自由选择发布哪个分支上的特性；如果新版本出现缺陷，可以直接在主干上进行修复或者使用hotfix分支修复，无须考虑其它分支
• 如果分支过多，其中有个别分支生命周期过长，代码合并及验收成本会快速增加
• 该模式的注意事项：让主干尽可能一直保持可发布状态；每个分支的生命周期应该尽可能短；主干代码尽量与分支同步；一切以主干代码为准，尽可能不要在各特性分支之间合并代码
• 根据分支的存在周期和目的，“分支开发，主干发布”模式可以分为两种子类型，分别是特性分支模式和团队分支模式

分析

特性分支模式

• 在开发过程中，允许多个开发分支同时存在，且每个分支对应一个功能特性的开发工作。当分支特性开发完成，立即合入主干，其它开发中的分支需拉取主干上的代码，进行代码合并之后，才能再合入主干
• 该模式注意事项：分支的开发与测试周期尽量短（3天内）；开发人员每天与主干代码进行同步；不要从其它特性分支上拉取代码

团队分支模式

• 团队分支可以看做特性分支的一种特殊情况。即一组人在同一个分支上进行开发工作，而且该分支上通常包括一组相近或相关的特性集合的开发。此分支持续时间比特性分支的持续时间要长
• 常用于规模较大的团队（40人以上）共同开发同一款产品，团队被分为多个组，每组开发不同的系统组件。当一系列功能特性开发完成后，才对外发布新的软件版本，很容易成为典型的瀑布开发流程
• 团队分支模式在通信公司和产品研发或大型客户端软件产品研发中比较常见
  该模式注意事项：每个团队尽早向主干合入高质量的代码，即使不马上发布；向主干合入代码后，尽快使其达到可交付状态；其他团队尽早与新合入的主干代码进行同步

分支模式的演化

“三驾马车”分支模式

• 该模式是指软件开发团队仅维护三个分支，分别是开发分支、预发布分支和发布分支
• 开发分支就是所有开发人员提交代码的目标分支。当开发分支上有足够的新功能（或者即将接近既定的发布日）时，将该分支中准备发布的那些功能分拣到预发布分支上
• 预发布分支上只做缺陷修复、文档生成及发布相关的工作，不做新功能开发
• 发布分支是指预发布分支质量达标后，对外进行的发行版本

Gitflow分支模式

• 该模式包含Master分支、Release分支、Development分支、Feature分支、Hotfix分支
• 目前有很多企业都在使用的分支模式

Master分支是正式版本的发布分支

Release分支是用于质量打磨的预发布分支。当该分支质量达标就可以合入Master分支，同时也需要将代码合入Development分支

Development分支是对新功能进行集成的分支

Feature分支是为了开发某一功能特性，开发人员从Development分支上拉出的分支。当特性分支开发完成后，合入Development分支

Hotfix分支是用于修复Master分支上产生的缺陷的分支。当解决完缺陷之后，将代码合入Master与Development分支

GitHubFlow分支模式

• 该模式包含Master分支和Feature分支。在Feature分支上开发新特性，完成之后合入Master分支（创建Pull Request）
• 分支策略与版本发布周期有一定的相关性
• 软件开发周期极长的“项目制”团队和软件发布频率极高的“城际快线式”团队会使用“主干开发，主干发布”的分支策略。而次之的团队会使用“主干开发，分支发布”的分支策略。他们之间的团队会使用“分支开发、主干发布”的分支策略
• 当发布周期缩短到一定程度后，主干开发模式更具有优势，因为分支开发模式的合并成本会成为短周期发布的障碍。如果发布周期短于两周，软件团队就应该毫不犹豫的转向“主干开发模式”
• Feature分支工作步骤
  1. 从Master上创建新的分支，以这个特性或缺陷的编号命名该分支
  2. 在这个新创建的分支上提交代码
  3. 功能开发完成（自测通过），创建Pull Request（简称PR）
  4. Master管理员对这个PR进行审查，确认质量合格后，合入Master

版本发布模式

简述

• 版本发布模式有3种，分别是：项目制发布模式、发布火车模式、城际快线模式
• 发布模式包含3个约束变量，即交付时间、特性数量、交付质量

分析

项目制发布模式

• 针对一个特定版本，在确定了版本的特性数量和质量标准以后，再估计版本交付周期，这相当于固定了特性数量和质量要求，那么团队可能交付的时间点也就相对固定了
• 通常项目交付周期较长，参与人员众多
• 在研发过程中的需求变更，需要重新确定项目的交付时间

发布火车模式

城际快线模式

• 该模式是指在发布三要素中，固定其中的时间和质量两个维度，且时间周期相对较短（如一周或几天），针对那些在发布时间点以达到固定质量标准的特性进行一次性发布
• 该模式的特性：一是发布周期间隔较短；二是负责特性开发的团队可以自己选择搭乘那列城际快车，而不必提前很长时间确定下来
• 城际快线模式是“持续交付2.0”所提倡的模式