持续交付下的开发分 支模型 姚 文杰 wjyao@thoughtworks.com 1
概览 - 为什什么我们要谈持续交付和开发分 支模型 - 什什么样的开发分 支模型更更有利利于持续交付 - 主流的三种分 支模型 - 演进 优缺点 工具 - 总结及值得注意的事情
我们为什什么要做持续交付 更更短的交付周期 生产环境部署频率越来越快, 简化 生产部署流程, 且 自动化不不停机部署 更更好的质量量保障 在代码检查, 功能和 非功能验证, 以及部署各 方 面建 立较完善的质量量保障体系, 尤其是 自动化测试集 更更 高绩效的团队 包含业务, 开发测试, 和运维职能在内的 一体化团队, 以产品交付为共同 目标紧密协作, 共同承担责任 更更 高价值的产品 形成特性提出到运营数据 用户反馈验证的实验性交付闭环, 基于实际 用户反馈调整计划和需求
为什什么要谈开发分 支模型 团队代码库持续交付流 水线线上产品 产品代码
为什什么要谈开发分 支模型 代码版本管理理是 CI/CD 的基 石, 分 支模型是代码版本管理理的核 心
什什么样的开发分 支模型更更有利利于持续交付 你们是如何做代码版本管理理的?
理理想与现实 最近写了了 一堆 代码, 千万不不能 和他们冲突呀 我这两天什什么也没做, 一直在解决代码冲突 感觉 又得做 一次回归测 试才能放 心了了 提交代码 触发持续交付流 水线 提交代码 触发持续交付流 水线 DEV 远程代码库 一群 DEV 远程代码库 我应该提交到哪 里里 ( 哪 个分 支 )? 他的代码把 pipeline 又 搞挂了了! 你的代码影响到我 这 一块, 导致我的功能有 问题了了!
什什么样的开发分 支模型更更有利利于持续交付 常 见的问题 遵循的规则 集成的痛 : 1. 不不断出现的代码冲突 2. 解决冲突时的沟通和技术成本 CI/CD 的坏影响 : 3. 破坏流 水线的提交出现频率更更 高 4. 功能互相影响 5. 测试需更更加全 面仔细 ( 尤其是重复的 手 工测试 ) 合作上的坏影响 : 6. 人以及团队之间的互相指责 - 尽早集成, 尽早发现冲突 - 功能之间能够保持 一定隔离 - 尽量量将重复的事情 自动化 - 保证团队成员的每 一次提交都具有原 子性 - 以代码事实为基础, 不不追究个 人
项 目 V1.0 Tech Lead 小张 15 个 人团队 要敏敏捷 : 全功能团队, 站会, 故事卡, 回顾会议 前后端 2 个模块, 有 4 个 大功能和 一些 小功能 要持续交付 :CD 流 水线 30+ 天上线 一次
开发分 支模型
GITFLOW Dev QA QA Dev
GITFLOW 的优点以及 PIPELINE 的设计 分 支之间清晰的职责区分 功能隔离和安全性 持续交付流 水线的设计 每个功能分 支及主分 支 一条 pipeline 发布期间, 需要为 release 分 支创建 一条对应的分 支 用于测试和部署 pipeline 的 生命周期和分 支 一样 长 较多 手动更更改流 水线配置的步骤
项 目 V2.0 Tech Lead 小张 30 个 人团队 要敏敏捷 : 全功能团队, 站会, 故事卡, 回顾会议 前后端 8 个模块, 有 十 几个 大功能和 一些 小功能 要持续交付 :CD 流 水线 15-20 天上线 一次
GITFLOW 的困扰与缺陷 Dev 集成还是 一个 大的 工作量量呀, 好头疼 别 人那么多代码, 不不敢重构呀 好困惑, 什什么时候删分 支, 什什么时候合分 支, 什什么时候删这个 pipeline 我是新 人, 我只知道我当前 工作的这条分 支是 干什什么的 QA PM 每次都要重复测试 一些功能点 测试 工作太密集,QA 都不不够 用了了 这个上线的周期还是有点 长呀 大家抱怨 比较多呀, 是不不是我们的模式有点什什么问题 上线周期太 长 巨 大的 Merge, 不不敢做重构 大量量的回归测试 流 水线数量量与分 支强相关, 维护成本 高 本身 比较复杂, 有 一定学习成本
GITHUB FLOW Version/Release Tag
GITHUB FLOW 的优点与 PIPELINE 的设计 交付周期更更短了了 团队关于代码的交流更更多了了, 共识也逐渐产 生了了 测试的 工作也减少了了
GITHUB FLOW 的困扰与缺点 Dev 他怎么这么不不负责, 看都没看就 merge 这个 PR 他的这次提交简直太多了了, 我今天 一天就 review 这份代码吧 他总是不不同意我的 PR, 是不不是对我有意 见 这个分 支还有没有必要存在? 对 人的依赖很 大 Code Review 周期太 长 很棒, 这减少我的很多重复劳动 无法避免代码和功能冲突, 隔离 QA 性不不够好 很棒! 但是, 这个 交付周期可不不可以再快 一点 PM
改善的 方法 - 特性分 支 Important rule 开关在代码中存在的地 方越少越好 删除不不再被需要的开关, 以免留留下技术债 Side benefits A/B 测试 始终处于可发布状态 Side effect 随着代码的膨胀, 隔离的准确性会进 一步降低, 维护成本变 高
项 目 V3.0 Tech Manager 小张 100+ 个 人,4+ 个团队 要敏敏捷 : 全功能团队, 站会, 故事卡, 回顾会议 前后端 十 几个模块, 有 几 十个 大功能和 一些 小功能 要持续交付 :CD 流 水线 最快 2 天上线 一次
TRUNK BASED DEVELOPMENT
TBD 的优点及 PIPELINE 的设计 容易易理理解, 易易于实施 集成迅速, 快速失败 方便便测试 发布可控
HOW TO GET FROM GIT FLOW TO TRUNK BASED DEVELOPMENT 特性开关 (Feature toggle) 代码审查 (Code review) 抽象分 支 (Branch by abstraction)
BRANCH BY ABSTRACTION "Branch by Abstraction" is a technique for making a large-scale change to a software system in gradual way that allows you to release the system regularly while the change is still in-progress. - Martin Fowler
BRANCH BY ABSTRACTION Original structure
BRANCH BY ABSTRACTION Step 1 Step 2 Step 3 Step 4
CODE REVIEW 结对编程 Pull Request ( 与 Github Flow 结合使 用 ) 定期的团队代码审查 ( 代码审查优先于开发新需求 )
SUMMARY
SUMMARY Name Git Flow Github Flow Trunk Based 集成周期 较 长, 取决于功能的 大 小, 往往会 比较 长 较短, 依赖 reviewer 的 review 时 长 最短, 每次原 子性提交就是 一次集成 代码隔离性 较好, 各个功能之间没有代码和逻辑的牵扯 需要借助 feature toggle 等 工 具保证隔离性 需要借助 feature toggle 等 工具 保证隔离性 对 pipeline 的影响与维护 要么不不健全 要么不不容易易维护 ( 数量量和动作上 ) 运作在主分 支上,PR 上也可 以进 行行简单代码测试 / 检查 运作在主分 支上 对测试的影响较多重复的回归测试集中在主分 支上集中在主分 支上
需要注意的事情 往往存在多种模式混合使 用的场景 小步提交和原 子性是保证所有内容的基础
REFERENCE Gitflow: http://nvie.com/posts/a-successful-git-branching-model/ Github flow: https://guides.github.com/introduction/flow/ Trunk based development: http://trunkbaseddevelopment.com Feature toggles: https://martinfowler.com/articles/feature-toggles.html Branch by abstraction: https://martinfowler.com/bliki/branchbyabstraction.html Code Review: 超越 审 查 评 的代码回顾 : http://insights.thoughtworks.cn/code-review/
THANKS Questions?