DevOps系列之 —— DevOps概览（一）软件产业和交付模式发展趋势
DevOps系列之 —— DevOps概览（二）新型软件技术及交付模式
DevOps系列之 —— DevOps概览（三）DevCloud HE2E DevOps 框架及其主要服务
DevOps系列之 —— 持续规划与设计（一）敏捷项目管理理念与方法实践
DevOps系列之 —— 持续规划与设计（二）规划与设计
DevOps系列之 —— 持续规划与设计（三）敏捷项目管理的方法【Kanban 与 Scrum】
DevOps系列之 —— 持续规划与设计（四）敏捷需求管理【用户故事 & 敏捷估算】
DevOps系列之 —— 持续规划与设计（五）团队与协作
DevOps系列之 —— 持续规划与设计（六）华为敏捷项目管理企业实践
DevOps系列之 —— 持续开发与集成（一）持续集成理念、方法及实践
 
DevOps 系列文章，持续更新中 ~~~

代码托管与分支策略

版本管理

• 我们先来看下面两幅对比图，这两幅图的区别是向主干分支合并代码的周期不同，那么哪一幅图更符合持续集成的原则呢？
  
• 很显然，答案是第二幅。DevOps 团队通过基于主干开发的方式践行持续集成，让开发者更频繁地将代码合并到中央仓库，理想的情况下是每天几次
• 当团队能够经常合并较小的变更时，将减少合并的复杂性，促使提前发现问题

版本规划

• 产品的生命周期中，会遇到多种渠道获得的各种各样的需求，比如部门内部由于运营需要提出的需求，产品经理提出的需求，以及通过用户投诉或反馈得来的需求，通过研发人员对资深产品和竞品的体验分析得来的需求，如何将这些需求落地，做好版本规划呢？
• 软件版本管理，不只是分支管理
  • Build Manager？
  • 配置管理员？
  • IT Support？
• 版本管理的目的
  • 版本控制，历史信息
  • 团队协作并行开发
  • 过程管理（变更、审批、流程）
  • 问题追踪

持续交付，从代码分支策略，看到的是软件的发布机制；发布的过程，是开发与运维的沟通

工作流

1. Git Flow

• 用于记录历史的分支

  • Git Flow 使用两个分支来记录项目开发的历史，而不是使用单一的 Master 分支。在Git Flow 流程中，Master 只是用于保存官方的发布历史（一般设置成分支保护模式），而 Develop 分支才是用于集成各种功能开发的分支
    

• 用于功能开发的分支

  • 每一个新功能的开发都各自使用独立的分支。在创建新的功能开发分支时，父分支选择 Develop（而不是 Master）。当功能开发完成时，改动的代码被合并（merge）到 Develop 分支
  • 很多时候，Feater 向 Develop 合并的时候，会提交一个合并请求，有专门的技术负责人进行审核，把控代码质量，审核通过才允许合并
  • Feater 是一个临时分支，生命周期随着功能开发完成而结束
    

• 用于发布的分支

  • Release 分支基于 Develop 分支创建，我们可以在这个 Release 分支上测试，修改 Bug 等。这个分支的创建意味着一个发布周期的开始，也意味着本次发布不会再增加新的功能。在一切准备就绪的时候，合并该分支到 Master 和 Develop，并且用版本号打上标签
    

• 用于维护的分支

  • 发布后的维护工作或者紧急问题的快速修复也需要使用一个独立的分支（Hotfix）。这是唯一一种可以直接基于 Master 创建的分支
  • 问题被修复后，所做的改动合并入 Master 和 Develop 分支
  • Master 上使用更新的版本号打上标签
    

2. Github Flow

• Github Flow 工作流仅具有特性分支和主干分支，非常简单和干净
• 将所有内容合并到主干分支和部署，最大限度地减少了“库存”中的代码量
• 基本原则：任何主干上的版本都是可发布的
• 开发人员创建的新分支，无论是新增特性，还是修改bug，分支命名应该具有较好的描述性。其他人就可以看出分支的意图
• 特性分支创建成功后，无论什么操作，新增、修改或是删除文件，都可以及时地提交到特性分支，便于跟踪开发速度
• Github 工作流特点之一：pull request，可以为提交初始化一个讨论组，在开发过程中的任何时候都可以创建一个 pull request（甚至没有写代码，只是想寻求他人帮助 / 功能开发完成，让其他人检查代码），一旦 pull request 被审核通过，新功能就进入了产品中等待验证
• Github 工作流隐含的问题：每次合并新功能，主分支的代码是应该及时发布的，但实际中常常不能做到这一点，比如 APP 发布前需要一定的审核时间（如何解决此问题，请继续往下看 Gitlab Flow 工作流）
  

3. Gitlab Flow

最大的原则：上游优先，即只存在一个主分支 Master，它是所有其他分支的上游，只有上游分支采纳的代码变化，才能应用到其他分支

• 带生产分支工作流

  • 创建一个反映已部署代码的 PRODUCTION 分支

  • 将 MASTER 合并到 PRODUCTION 分支来部署新版本
    

  • 优点

    • 可以随时检出 PRODUCTION 分支，查看生产代码
    • 可以清晰查看提交合并记录
    • 可避免 Git Flow 中常见的发布，打标签和合并的开销
• 带环境分支工作流
  • MASTER 分支部署测试环境
  • MASTER 分支向 PRE-PRODUCTION 分支合并，部署预生产环境
  • PRE-PRODECTION 分支向 PRODUCTION 分支合并，部署生产环境
  • 当要部署预生产环境时，它会创建从测试分支到预生产分支的合并请求，而将预生产分支合并到生产分支则会触发代码的直接上线。这种变更的提交，优点是只向下游流动的工作流，可确保所有的变更在所有环境中都经过测试, 但是，在某些极端的情况下，可能需要执行更多的手工测试，这就导致无法执行上述的从测试环境到预生产环境，到生产环境的标准流程，那么我们可以直接从特性分支 cherry pick 一个合并请求，
    到其他的下游分支
    
    • 优点
      • 这种变更提交（commits）只向下游流动的工作流可确保所有变更在所有环境中都经过测试
• 带发布分支工作流
  • 只有一个 MASTER 分支
  • 每次需要发布时拉取发布分支，并对发布分支打标签
  • 发布分支（STABLE）以 MASTER 分支为起点，尽可能晚的创建
  • 在一个发布分支被公布后，仅有严重错误的修复能被包括在该分支中
  • bug修复也可以独立地创建分支（建议以 fix 前缀命名），它属于临时分支，bug 解决后，可以删除改分支
    
  • 优点
    • 分支数少，易于管理
    • 发布分支明确，从项目管理维度可以明确的判断 bugfix 需要合入分支的策略

企业实践

1. Google

• 工作流程
  • 开发者先创建文件的本地拷贝，这叫做 “工作区”（workspace）。完成开发后，工作区的快照分享给其他开发者进行代码评审。只有通过了评审，代码才能合并到中央仓库
    
• Google 采用 “主干分支”（trunk-based development）。代码一般提交到主分支的头部。这样保证了所有用户看到的都是同一份代码的最新版本
• “主干开发” 避免了合并分支时的麻烦。Google 一般不采用分支开发，分支只用来发布。大多数时候，发布分支是主干某个时点的快照。以后的除错和功能增强，都是提交到主干，必要时 cherry-pick 到发布分支
• 由于不采用 “分支开发”，Google 引入新功能，一般在代码中使用开关控制。这避免了另起一个分支，也使得通过配置切换功能变得容易，一旦新功能发生故障，很容易切换回旧功能。等到新功能稳定，再彻底删除旧代码
  

2. 华为云

开发流程

• 三种不同角色的项目成员分工协作
  • Developer 的任务是开发特性需求，修改问题，对合入代码质量承担第一责任
  • Reviewer 的任务是对业务逻辑的正确性，代码规范的遵从度，代码架构等方面进行检视，并提出修改意见，若有多名 Reviewer，分工可各有侧重
  • Committer 的作用是审核代码的整个解释过程，申请入库的代码质量需要其把控，对审核的代码质量承担共同的责任（建议担任 committer 角色的人员应作为 reviewer 成员之一）
• IT 工具触发门禁检查，门禁检查成功后，通知 reviewer 检视
• reviewer 收到代码检视通知后，对代码进行检视并提出代码检视意见
• Developer 收到检视意见后，完善代码并闭环检视意见，更新代码入库申请
• 最后，Committer 根据工具检查的结果和 reviewer 的意见以及闭环情况，并从代码和架构的长远视角进一步对代码进行审核，决策是否接纳本次代码入库申请
• 在保证代码质量的前提下，工具门禁检查和人工代码检视可并行执行
• 工具检查关注的是圈复杂度，嵌套层数，有效注释比例，编译告警，冗余代码，危险函数，重复代码，PC link 告警，编程规范等等
• 专家评审关注的是命名准确，功能耦合以及架构逻辑的错误
• 在不同的项目团队中，committer 还可对代码检视的策略进行灵活调整

分支策略

工作流的选取

• 项目版本发布周期
  • 发布周期较长：可选择 Git Flow 工作流，可以很好的解决新功能开发，版本发布，生产系统维护等问题
  • 发布周期较短：可选择 Github 工作流

• 分支规则：Feature 分支向 Master 分支合入
  • 从 Master 分支拉取 Feature 分支
  • 根据版本节奏，Feature 分支向 Master 分支合入发布版本代码
  • 优点
    • 分支简洁，可以保证主分支的随时可发布特性，可以保证热补丁版本的快速上线，提升客户满意度
  • 问题
    • 这种分支策略对自动化测试等基础设施要求比较高

小结

• 生产（master）严禁直接提交代码
• 在合并到 master 之前执行代码审查，而不是事后审查
• 功能分支命名应该体现当前功能
• 重视测试，测试全自动化，合入前确保代码的正确性
• 提交信息（commit message）应体现意图

最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注😊