全部产品
存储与CDN 数据库 安全 应用服务 数加·人工智能 数加·大数据基础服务 互联网中间件 视频服务 开发者工具 解决方案 物联网
云效

分支模式

更新时间:2017-09-29 20:07:30

分支模式是RDC支持的三种研发模式的一种。每种研发模式,不仅意味着其中各(类)分支的使用方式,也意味着RDC能够向用户提供的相应支持,分支模式也不例外。事实上,RDC对分支模式提供了强有力的支持:用户可以只需要关心集成和发布哪些feature分支,而对release分支创建和管理、分支间合并等一系列工作,可以托付给RDC系统完成。

本文详细介绍分支模式下,各(类)分支的使用方式。关于RDC提供的相应支持,详情请阅读分支模式下的流水线

master代表最新发布版本

master分支代表最新发布版本。当需要最新发布版本的内容时,直接取分支末端即可。

不论其他哪类分支,都建议一般从master分支创建,并且经常从master分支合并,以便跟上“潮流”,减少将来集成时的各种问题,比如代码合并冲突。

每当软件正式发布前,系统会确保它基于master最新。

每当软件正式发布后,系统会把相应内容合并回master,以便让master分支始终代表最新发布版本。

一般来说,使用者不要直接“写”东西到master分支。把“写”的工作交给系统适时自动完成。

在各feature分支上开发

一条feature分支(又称变更分支、开发分支),通常用来承载一个缺陷的修复,或者一个需求(如果不是很大的话)的开发,或者任务分解后一个任务的开发。

一般来讲,基于master分支最新版本创建feature分支。然后在feature分支上开发、测试,直到这个feature功能完成,质量OK,准备好去集成和发布。

release分支上的集成

release分支用于集成和发布。基于master分支最新版本创建一条release分支,然后把想要集成的各条feature分支合并到这条release分支,进行部署和测试工作。

如果有新的feature分支要加入本次集成,那就把它也合并进这条release分支,然后再次部署并测试。

如果测试发现问题,就到feature分支上修复,然后把它再次合并到release分支,把修复带到release分支。

当然如果一个feature的问题太多太大,那干脆就放弃它。也就是说,新建一条release分支,把其他feature分支都合并过去,唯独不再合并这条feature分支。

就像master分支一样,release分支也是由系统自动管理的。使用者不要直接在上面改代码,代码修改请总是在feature分支完成。

release分支上的发布上线

当release分支上的质量足够好,想本次想上线的功能也都具备之后,就要考虑发布上线的问题啦。如前面讲的,发布上线前,会确保它基于master最新。而发布后会把release分支合并回master,让master代表最新发布版本。

以上几节介绍的内容,见下图:

从feature分支到release分支

多个环境/流程时

假定要想集成发布上线,要经过日常测试环境上的测试这个流程,还要经过预发环境上的测试这个流程,那么两个流程用一条release分支就有些不合适。因为两个流程可能同时在测不同的feature分支集合。

分支模式用这个办法避免这个问题:每一个测试环境,也就是每个流程,关联它自己的release分支。日常测试、预发测试这两个环境(也就是两个流程),分别关联两条release分支。这样就不会相互影响。推而广之,为正式运行环境,也对应一条release分支。也就是说,每个环境都有对应的release分支。

当把集成成果从一个环境传递到下一个环境时,就是把一个环境下已合并到一起的feature分支,再往另一个环境对应的release分支上合并一遍……这么做有点儿笨。系统实际的做法是,基于master分支创建另一个环境对应的release分支,然后把前一个环境对应的release分支合并到新的release分支上。

本节介绍的内容,对应下图:

各release分支

小结

以上就是关于分支模式这种研发模式的原理性介绍。更多细节在分支模式下的流水线中讲解。

本文导读目录