05.如何为团队设计简单高效的配置管理策略(分支策略)笔记

01.配置管理/版本管理到底要解决什么问题?

研发过程全景

 

 

 

 

管理属性过程:建立"规划版本"的管理能力,完整跟踪要做什么,怎么做,进展如何

工程属性过程:建立"交付版本"的管理能力,完整跟踪谁在左,如何实现,在哪里,质量怎样

软件所有的需求,都是假设,都是如果我实现这个东西,给客户带来什么。

 

配置管理/版本管理到底需要管什么?

n  版本的两层含义:

u  管理属性(规划版本):我们希望团队在这个版本里卖弄交付什么?

u  工程属性(交付版本):团队真的在这个版本里卖弄交付了什么?

n  管理管理/版本管理的目的就是让每个参与研发过程人清楚知道

u  我们要做什么?

u  我们正在左什么?

u  我们做完了什么?

n  配置管理/版本管理作为研发过程承上启下的衔接点,不仅仅是管理代码,还需要考虑

u  团队模型

u  测试模型

u  CI/CD流水线

 

持续交付的挑战:软件开发中的三级耦合

代码级耦合:一个开发人员的修改即可影响整个系统团队规模<20

组件级耦合:延迟影响至运行时,多团队协作称为可能,接口定义不通过用,无法跨技术栈使用

服务级耦合:延迟影响至生产环境、多团队、多技术栈协作称为可能,接口是视定义、服务自治。

 

分支策略目的

n  代码级解耦

n  允许不同的开发人员或团队在同一份代码的不同副本上同步工作

n  允许不同目的/属性的代码同时存在,并相互关联跟踪

u  主干:master

u  特性:feature

u  补丁:hotfix

u  测试:test

u  发布:release

 

-----------------------------------------------------------------------

02.配置库拆分

 

考虑库是否合理‘

可部署单元

可以独立进行编译,调试,测试,CI/CD何部署代码的边界

拆分方式

u  代码依赖改成组件包依赖

u  服务及依赖(微服务)

u  数据分离处理

减少可部署单元的好处

u  减少代码库,提高代码编译/调试/测试/CI/CD和部署速度

u  降低犯错可能性

u  推动模块化,组件化,更容易引入和替换(开源替代方案)

 

 

配置管理的坏味道

n  滥用分支

n  不同分支上的代码无跟踪关系(不使用merge迁移代码,而是从新提交)

n  不同分支上留存不同代码

n  过多使用挑拣代码操作

n  需要在拉去分支的时候从新配置CI/CD

n  不同分支产生不同的制品

 

 

 

 

 

-----------------------------------------------------

分支策略的演进策略

 

 

 

 

按职能划分的分支结构:

l  团队采用瀑布式,职能团队(开发、测试、运维):各自需要分离独立的代码版本以便划分清晰的职能范围

l  独立测试部门就是典型的表现

l  单体架构决定了每次合并回产生大量变更,进而冲突和挑拣代码编程团队的痛点问题

l  单体架构决定了每次合并会产生大量变更,进而冲突和挑拣代码编程团队的痛点问题

l  运维怼发布枪口的严格控制造成大量未经发布到生产环境的代码积压,形成大量的制品(浪费,未实现价值);同时增加开发和测试的工作粒度,增加复杂度

严格控制的发布窗口并不会提升软件质量,而是提高了软件质量风险流程制约造成团队试图通过减少代码发布量控制质量(增量发布)、进而造成生产环境丧失从新部署能力,不同代码分支代码无法相互跟踪

l  代码库变成一堆垃圾

 

 

 

 

 

主干开发,分支发布(主干开发模式):

l  优点:

n  简单

n  跨职能共享的代码库

n  支持开发/测试混合工作

n  并行RC和Dev版本

n  需要更少的可能部署单元作为repo的代码边界

n  简化CI/CD操作,直聘唯一性容易保证

l  缺点:

不支持更多版本并行

不能适应更大国模的单一代码库(需要引入功能开关左代码逻辑解耦)

 

 

特性分支,主干发布

l  优点:

跨职能共享代码库

更多的代码并行开发

Master分支代码更加健壮(不允许直接嵌入,必须通过merge)

l  缺点:

n  Feature分支存活时间过长容易造成大量冲突

n  不利于CI/CD配置,每条feature分支都需要独立进行CI/CD配置

n  不利于确保制品唯一性

 

 

 

 

拉取请求——解决特性分支的缺点

n  拉去请求不是合并

u  拉去请求(pull request):

l  要求对方将代码“拉”进去,所以叫做"拉取"

l  代码还没有被合并,所以叫做“请求”

n  不要再需要合并的时候菜创建拉去请求

n  拉去请求可以

u  社交编程,围绕“代码变更”进行代码走查/评审

u  跟踪代码评审任务

u  方便跟踪最终版本代码状态(显示HEAD diff而不是commit diff)

u  保护目标分支(可以是master,也可以是其他用途分支)

u  简化CI/CD配置,只需要配置一次,可以支持无数条feature分支

u  支持按用户故事进行开发

 

-------------------------------------------

最佳分支策略范本

就是没有分支

 

posted @ 2020-03-29 00:50  艾小小雨  阅读(804)  评论(0编辑  收藏  举报