持续交付2-版本控制

Posted 2020-12-16 chengmuyu

版本控制

版本控制系统:用于维护应用程序每次修改的完整历史,包括源代码,文档,数据库定义,构建脚本,测试等.

当团队人数超过一定数量时,版本的冲突会日益增多,如何较好的进行版本控制管理,就变得非常重要.

分支与合并

分支的主要目的时帮助并行开发,而不互相影响.

团队中的分支使用情形:

1. 物理上:因系统物理配置而分支,即为了文件,组件和子系统而分支
2. 功能上:因系统功能配置而分支,即为特性,逻辑修改,缺陷修复和功能增加等
3. 环境上:因系统运行环境而分支,即为硬件环境不同而分支
4. 组织上:因团队工作量而分支,即为活动/任务,子项目,角色和群组而分支
5. 流程上:因团队的工作行为而分支,支持不同规章政策,流程和状态而分支.

合并:把分支上的一些修改复制到另一个分支的过程

分支的合并往往是冲突的开始,而冲突则意味着风险.

减少分支合并冲突的方式:

1. 早分支.创建更多分支来减少在每个分支上修改.这种方式只是分散了单次合并冲突,并没有解决核心问题
2. 推迟分支.谨慎的创建分支,可能是每个发布才创建一个分支(稳定版本,且便于修复问题).这种方式是加速问题暴露,尽早解决.

分支与持续集成

持续集成是不断向主干分支进行代码合并,保障主干分支的良好运行.持续集成不主张多分支.
一个更可控的分支策略是:只为发布创建长周期的分支.

在这种模式下,新开发的代码总是提交到主干分支上,只有在发布分支上修改缺陷时才需要合并,而这个合并是从分支合并会主干.而只有非常严重的缺陷修复才会从主干分支合并到发布分支上.
因为代码一直处于可发布状态,所以也就更容易发布.分支越少,合并和跟踪分支的工作就越少.

实际开发中可能团队人数较多,但是这并不影响主干分支开发模式,因为实际大家编辑相同文件且发生冲突的可能较小,如果较多的话,说明项目需要进行组件化拆分,并确保组件间的松耦合.

主干分支

主干分支是持续集成的唯一分支管理方式.

优点:

1. 确保所有代码被持续集成
2. 确保开发人员及时获得他人的修改
3. 随时解决合并冲突,避免分支合并时大量冲突的情形.

同时,进行复杂修改时,将它拆解为小需求就可以很好的在主干分支上进行.

主干分支存在非可发布的状态的情形,如果针对这种情况就主张多分支的话,分支管理同样也存在这种状态,同时分支管理更加复杂,不可控因素会逐渐增多.

如何使用主干分支管理一个多开发人员,多版本发布的大型团队?
良好的组件化,增量式开发和特性隐藏.

按发布创建分支

按发布创建分支:在版本即将发布前,创建分支,用于测试和验证,开发依旧在主干分支进行.

发布分支只允许进行缺陷修复,不允许进行功能开发,以减少合并冲突情形,同时提交到发布分支的补丁,最好立即合并到主干分支上.

同时团队还应该尽量避免多分支开发的情形,比如老版本客户不愿意进行升级操作.同时大型团队往往会存在多个业务线,同一个版本完成所有开发也不现实,这是进行组件化就非常重要.

发布频率如果到达一周一次时,就没有必要创建发布分支了,主干分支发布即可.发布分支不允许再创建分支.

按功能和按团队来创建分支都是不推荐的,因为这会存在大量分支,然后造成集中合并,影响代码的稳定性.同时不同分支的差异会越来越大,团队间互不了解,风险也会逐渐增大.

• 可控分支

可控分支创建的理由:

1. 发布新版本
2. 调研新功能或重构
3. 需要对应用程序做比较大的调整,但又无法较好的避免分支时,创建临时分支

可控分支创建的唯一目的:对代码进行增量式或"通过抽象来模拟分支"方式的修改