带你读《代码管理实践10讲》——一、量体裁衣,寻找适合你团队的代码协同模式(2)

简介: 带你读《代码管理实践10讲》——一、量体裁衣,寻找适合你团队的代码协同模式(2)

带你读《代码管理实践10讲》——一、量体裁衣,寻找适合你团队的代码协同模式(1):https://developer.aliyun.com/article/1480954

2. 设计团队的代码协同工作流

基于前面介绍的代码协同模式,企业/团队根据项目的实际情况可以灵活定制自己的代码协同工作流。通过对以下问题的回答,可以找出最适合的代码协同工作流。

1团队能力和项目类型评估

是否开源?

开源包括针对外部的代码开源,还包括企业内部开源(内源)。

 

如果代码仓库选择了开源(无论是外部开源,还是内源),为管理方便可以在仓库中仅定义两种用户角色:

 

∙        维护者。维护者可以是一个人或者一个团队承担项目维护者的职责,维护者具有仓库读写和管理权限。管理权限包括:批准代码评审通过,合并代码评审等。

∙        贡献者。贡献者具有只读权限,需要通过 GitHub-Flow 或者 AGit-Flow 方式向仓库贡献代码。

对于复杂的需要多人协同开发的特性,可以采用 GitHub-Flow 模式。通过创建的派生仓库进行多人协同开发,开发完毕创建向上游仓库的代码评审。代码评审通过,将提交合入到上游代码仓库。

 

对于简单的特性开发,建议采用 AGit-Flow 模式,用户执行 git 推送命令,直接在服务端创建代码评审。

 

 

 对处于开发中尚不具备合入质量的提交,为了避免本地数据丢失,或者希望在服务端触发持续构建(CI)检查代码质量,可以通过如下推送命令在服务端创建草稿模式的代码评审:

 

git push origin HEAD:refs/drafts//

草稿状态的代码评审不能被合入,但是可以触发CI构建,可以进行代码评审。

是否有旧版本需要维护?

通常互联网线上应用采用持续部署(CD)、主干分支发布。这种类型的项目一旦发现线上缺陷,直接在项目的主干分支上修复缺陷,修复缺陷的提交连同新特性一同发布到线上。这种类型的项目不需要对旧版本进行维护。

 

有的项目无法采用持续部署、持续发布,新版本有较长的开发周期,就需要对已发布的一个或多个版本进行维护。这样的项目就需要在代码仓库中存在一个或多个维护分支。例如:安卓手机的 Android 系统、苹果手机的 iOS 系统通常在每年发布一个大版本,历史发布版本提供长达几年的维护期,这就需要在产品的代码仓库中创建一个或多个维护分支。

 

不同的项目对于维护分支可能有不同的命名规范,例如:maintmaint-2.0maint-3.0

是否使用CI和代码评审?

使用持续构建(CI)和代码评审,可以确保贡献者提交的正确性和代码质量,是软件项目高质量交付的利器。缺乏CI能力,也可以使用代码评审,不过缺乏CI的代码评审更加消耗评审人的时间,且难以保证代码的正确性。

 

 对于缺乏代码评审文化、缺乏单元测试、不具备CI条件的项目,往往跳过代码评审,这种类型的项目通常采用类似CVSSVN的共享分支协同模式。

 

即使采用代码评审的项目,对于多人协同开发的复杂特性通常创建一个长期的特性分支,多人在同一个特性分支进行代码协同时,通常也采用共享分支协同模式。

 

 

对于共享分支协同的建议:

 

∙        多个开发者向服务端仓库的同一个分支推送,先推送者成功,后推送者遇到非快进式推送被拒绝,需要采用正确的行为规范,避免强制推送造成其他人的提交被覆盖、丢失。推荐的操作方式是:

◦        推送之前先执行拉取和变基操作:git pull --rebase

◦        再执行推送操作:git push

 

∙        使用保护分支功能,设置被保护的分支不能强制推送,不能被删除。这样向保护分支推送时需要采用上面的操作建议,先和服务器同步、变基操作,再推送。

∙        当发现推送了错误的提交,希望采用强制推送覆盖服务器上推送的提交时,不要使用 git push --force,而是使用 git push --force-with-lease命令,为强制推送增加一份保险。注意:替换的服务器端提交如果已被他人获取,强制推送可能为他人带来困扰。

根据CI和代码评审的频率来判断项目的规模

当代码仓库的主干分支上有多个待合并的代码评审(CR),合并其中一个CR到主干,主干分支上的代码会发生变化,这会导致其他尚未合并的 CR 的构建状态变得没有意义,需要重新执行构建以确保正确性。

 

总的构建规模和CR数量关系为 O(n2) ,庞大的CI构建规模造成巨大的时间成本、计算成本的浪费,此外CR需以排队构建方式合入主干分支,导致项目协同规模受限。

 

我们可以采用下面的公式判断项目协同规模,决定是否采用集成分支以并行方式合入代码、降低 CI 构建数量。

 

项目复杂度 = 每日新建CR数量 / 每日串行CI构建数量

每日串行CI构建数量 = 8小时 / 单次CI构建时间

 

或简记为:

项目复杂度 = NT / 8

 

其中:

∙        N:每日新建 CR 数量。

∙        T:单次CI构建时间(单位:小时)。

当项目复杂度大于等于1,视为中大型项目,需要引入集成分支提升 CI 构建效率,CR先批量合并到集成分支,再合入主干。

 

当项目复杂度小于1,视为小型项目,仅使用主干分支即可,CR直接合入主干分支。

2示例:小型项目(无维护分支)协同规范

对于小型项目(无维护分支),采用主干开发模式。存在一条主干(如 master分支),功能开发通过特性分支模式或者 AGit-Flow 模式创建评审,代码评审触发持续集成(CI),评审通过之后,代码直接合并到主干分支。

 

协同示意图如下所示,其中提交之间的箭头方向表示的是时间从老到新的方向。

 

image.png

a项目成员管理

项目成员分属三个角色:管理员、开发者和贡献者。

 

∙        管理员:由一位或几位核心成员担任,具有对仓库完全的读写权限。

∙        开发者:固定的项目成员,对于仓库中非保护分支具有完全的读写权限。

∙         贡献者:团队之外的成员属于贡献者,仅有仓库的只读权限。

 

 

b分支的命名和管理

设置一条主干分支作为仓库的默认分支。主干分支通常命名为mastermain,由仓库管理员在仓库初始化时创建。

 

分支管理规范:

 

∙        可以使用通配符“*”设置保护分支,即所有分支均被保护。

∙        管理员和开发者能够在仓库中创建新分支,或者在推送评审模式启用下,任何人均可通过创建评审单的方式创建新分支。

∙        如果所有分支均被保护,则开发者创建的特性分支也需要使用AGit-Flow 工作流创建代码评审,将提交合并到特性分支中。

∙        向特性分支发起的代码评审,默认采用变基(rebase)方式合并,以避免在特性分支产生合并提交。

∙        向主干分支发起的代码评审,默认采用非快进合并(no-ff merge)方式合并。这种方式一定会产生一个合并提交,在合并提交中记录代码评审 CR 的编号和 CR 的描述信息。

∙        特性分支合入到主干分支时,默认选择合并后删除分支,避免过时的特性分支在仓库中堆积。

c创建代码评审

可以采用三种方式创建代码评审:GitHub FlowAGit Flow、分支评审模式。代码评审创建、更新会触发持续集成。

操作略。

 

 

 

d持续集成(CI

针对如下场景触发持续集成:

 

∙        向主干分支、特性分支的代码推送,触发持续集成。

∙        创建和更新 CR,触发持续集成。

∙        CR的目标分支被更新,触发持续集成。为避免 CR 构建规模造成的资源浪费,会检查开启的 CR 数量,当仓库复杂度超过阈值(NT/8 >= 1)则应关闭 CR 随目标分支变更而自动构建的设置。

3示例:大型私有项目(含维护分支)协同规范

对于大型项目(含维护分支),存在一条主干(如 master分支)、一条或多条维护分支(如 maint分支)。功能开发通过特性分支模式或者 AGit-Flow 模式创建评审。

 

创建或更新代码评审会触发持续集成,持续集成验证通过以及代码评审通过之后,首先将代码合入到集成分支(如next分支),触发集成分支的持续集成,验证通过后再整合入主干分支。

 

发行版本(如v1.0.0)的缺陷修复,需要创建一条维护分支(如maint分支),基于该维护分支创建热修复分支或者使用 AGit-Flow 模式创建针对维护分支的代码评审。

 

针对维护分支的代码评审验证通过后,先合入到维护分支,然后将维护分支回合到主干分支,以确保在历史版本中出现的问题在主干代码中亦得到修复,相同问题不再重现。

协同示意图如下所示,其中提交之间的箭头方向表示的是时间从老到新的方向。

image.png

a项目成员管理

项目成员分属三个角色:管理员、开发者和贡献者。

 

∙        管理员:由一位或几位核心成员担任,具有对仓库完全的读写权限。

∙        开发者:固定的项目成员,对于仓库中非保护分支具有完全的读写权限。

∙        贡献者:团队之外的成员属于贡献者,仅有仓库的只读权限。

b分支的命名

在仓库中设置如下常设分支:

 

∙        一条主干分支:master(或 main),同时作为仓库的默认分支,由仓库管理员在仓库初始化时创建。

∙        一条或多条维护分支:作为对一个或多个已发布版本的缺陷修复,仅合入缺陷修复提交,不合入新功能。可选的名称有:maintmaint-1.0release/1.0release/2.0等。Git项目使用 maint作为维护分支名,因为按照字母序,维护分支maint排在主干分支master之前,意味着更稳定。

∙        一条集成分支:该分支作为主干分支的集成分支,每一次集成的时候自主干分支重置,批量合入已经通过评审的 CR。批量合入后触发CI构建。Git项目中集成分支命名为next,字母序排在 master之后,视为不稳定的分支。

c分支管理规范

保护分支的设置:

 

∙        可以使用通配符“*”设置保护分支,即所有分支均被保护。

∙        管理员和开发者能够在仓库中创建新分支,或者在推送评审模式启用下,任何人均可通过创建评审单的方式创建新分支。

∙        因为所有分支被保护,开发者创建的特性分支、hotfix分支等也需要使用 AGit-Flow 工作流创建代码评审,将提交合并到相关分支中。

维护分支的管理规范:

 

∙        发现历史版本的缺陷后,基于存在缺陷最老的维护分支进行缺陷修复。

∙        可以采用创建 hotfix 分支的分支评审模式,或者采用 GitHub Flow 或者 AGit Flow 模式发起针对维护分支的代码评审。hotfix 分支的命名示例:hotfix/

∙        向维护分支发起的代码评审通过之后,合入相应的维护分支。之后将修复的维护分支逐级合并到更高版本的维护分支,将缺陷修复扩散到所有版本中,即“merging upwards”

∙        将修复后的最新维护分支合并到主干分支。

集成分支管理规范:

 

∙        将通过评审的多个 CR 自动或手工合入集成分支(如 next分支)。

∙        更新后的集成分支触发构建。

∙        集成分支构建成功后,通过界面发起集成分支到主干分支的合并请求。

主干分支管理规范:

 

∙        中大型项目设置了集成分支,因此针对主干分支的代码评审不直接合入主干分支。

∙        在集成分支(如 next分支)CI构建通过之后,重新合并到主干分支(以确保合并提交的提交说明的目标分支从 next调整为 master),更新主干分支提交,并触发构建。

特性分支规范:

 

∙        向特性分支发起的代码评审,采用变基(rebase)方式合并,避免在特性分支产生合并提交。

∙        向主干分支发起的代码评审,采用非快进合并(no-ff merge)方式合并。这种方式一定会产生一个合并提交,在合并提交中记录代码评审 CR 的编号和 CR 的描述信息。

∙        特性分支合入到主干分支时,选择合并后删除(可以设置为默认开启),避免过时的特性分支在仓库中堆积。

d创建代码评审

可以采用三种方式创建代码评审:GitHub FlowAGit Flow、分支评审模式。代码评审创建或更新会触发持续集成。

 

操作略。

e持续集成(CI

针对如下场景触发持续集成:

 

∙        向主干分支、集成分支、特性分支、维护分支的代码推送,触发持续集成。

∙        创建和更新 CR,触发持续集成。

∙        CR的目标分支被更新,不触发 CR 的持续集成,以降低 CR 构建的复杂度。

相关实践学习
基于函数计算一键部署掌上游戏机
本场景介绍如何使用阿里云计算服务命令快速搭建一个掌上游戏机。
目录
相关文章
|
10天前
|
Kubernetes 开发工具 git
带你读《代码管理实践10讲》——一、量体裁衣,寻找适合你团队的代码协同模式(1)
带你读《代码管理实践10讲》——一、量体裁衣,寻找适合你团队的代码协同模式(1)
60 1
|
10天前
|
Linux 开发工具 Android开发
带你读《代码管理实践10讲》——二、新一代高效Git协同模型AGit-Flow详解
带你读《代码管理实践10讲》——二、新一代高效Git协同模型AGit-Flow详解
26 0
|
10天前
|
安全 测试技术 开发工具
带你读《代码管理实践10讲》——三、评审协同如何提效,我们团队的4点思考
带你读《代码管理实践10讲》——三、评审协同如何提效,我们团队的4点思考
29 1
|
10天前
|
敏捷开发 安全 测试技术
带你读《代码管理实践10讲》——五、重评审还是轻评审,企业该如何选择代码评审模式?
带你读《代码管理实践10讲》——五、重评审还是轻评审,企业该如何选择代码评审模式?
45 0
|
10天前
|
Shell 开发工具 git
云效代码管理可以通过以下步骤统一更换地址链接
【1月更文挑战第21天】【1月更文挑战第102篇】云效代码管理可以通过以下步骤统一更换地址链接
126 1
|
8月前
|
运维 安全 数据可视化
免费托管代码到云效代码管理Codeup
本场景介绍如何提交代码到云效代码管理Codeup。云效Codeup提供免费、不限容量的云上代码托管服务,您无需担心计费问题。
753 0
|
10天前
|
敏捷开发 Serverless 测试技术
云效产品使用常见问题之代码管理单文件超过200m无法上传如何解决
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
10天前
|
Shell 开发工具 git
云效代码管理可以通过以下步骤统一更换地址链接
云效代码管理可以通过以下步骤统一更换地址链接
46 3
|
10天前
|
Java Serverless Maven
云效代码管理问题之代码仓库配置需要评审如何解决
云效仓库是阿里云提供的代码托管和版本控制服务,支持Git等多种版本管理工具;本合集聚焦于云效仓库的使用技巧、团队协作流程以及常见问题解答,旨在帮助开发者更高效地进行代码管理和协作开发。
1761 0
|
架构师 开发工具 开发者
《开发者评测》之云效代码管理Codeup评测活动获奖名单
云效代码管理Codeup评测活动获奖名单出炉啦!