参考极客时间,持续交付36讲
一切的源头,代码分支策略的选择
采用不同的代码分支策略,意味着实施不同的代码集成与上线流程,这会影响整个研发团队每日的协作方式,因此研发团队通常会很认真地选择自己的策略。
主干开发
主干开发是一个源代码控制的分支模型,开发者在一个称为 “trunk” 的分支(Git 称 master) 中对代码进行协作,除了发布分支外没有其他开发分支。
大多数时候,发布分支是主干某个时点的快照。以后的改 Bug 和功能增强,都是提交到主干,必要时 cherry-pick (选择部分变更集合并到其他分支)到发布分支。与主干长期并行的特性分支极为少见。为了保证主干上线后的有效性,一般会使用特性切换(feature toggle,灰度放量控制)。特性切换就像一个开关可以在运行期间隐藏、启用或禁用特定功能,项目团队可以借助这种方式加速开发过程。
特性切换在大型项目持续交付中变得越来越重要,因为它有助于将部署从发布中解耦出来。特性切换会导致代码更脆弱、更难测试、更难理解和维护、更难提供技术支持,而且更不安全。越来越多的特性切换会使得逻辑越来越混乱。
特性切换需要健壮的工程过程、可靠的技术设计和成熟的特性切换生命周期管理,如果不具备这三个关键的条件,使用特性切换反而会降低生产力。
优点:1、频繁集成,每次集成冲突少,集成效率高 2、享受持续交付带来的好处 3、无需在分支间切换
缺点:1、太多人工作在主干上,bug代码是灾难 2、借助特性切换保证线上运行正确性,引入新问题
特性分支开发
git flow
线上部署使用master分支,develop分支用来集成,feature分支用来开发。
github flow
GitHub Flow 是 GitHub 所使用的一种简单流程。该流程只使用 master 和特性分支,并借助 GitHub 的 pull request 功能。
在 GitHub Flow 中,master 分支中包含稳定的代码,它已经或即将被部署到生产环境。任何开发人员都不允许把未测试或未审查的代码直接提交到 master 分支。对代码的任何修改,包括 Bug 修复、热修复、新功能开发等都在单独的分支中进行。不管是一行代码的小改动,还是需要几个星期开发的新功能,都采用同样的方式来管理。
当需要修改时,从 master 分支创建一个新的分支,所有相关的代码修改都在新分支中进行。开发人员可以自由地提交代码和提交到远程仓库。当新分支中的代码全部完成之后,通过 GitHub 提交一个新的 pull request。团队中的其他人员会对代码进行审查,提出相关的修改意见。由持续集成服务器(如 Jenkins)对新分支进行自动化测试。当代码通过自动化测试和代码审查之后,该分支的代码被合并到 master 分支。再从 master 分支部署到生产环境。GitHub Flow 的好处在于非常简单实用,开发人员需要注意的事项非常少,很容易形成习惯。当需要修改时,只要从 master 分支创建新分支,完成之后通过 pull request 和相关的代码审查,合并回 master 分支就可以了。
GitLab Flow
GitLab Flow 针对不同的发布场景,在 GitHub Flow(特性分支加 master 分支)的基础上做了改良,额外衍生出了三个子类模型。
1、带生产分支。无法控制准确的发布时间,又要不停集成。2创建一个production分支方式发布代码
2、带环境分支。要求所有代码都在逐个环境中测试通过,为不同环境创建不同分支
3、带发布分支。用户对外界发布软件的项目,同时需要维护多个发布版本(android发版),尽可能晚从master拉取发布分支,bug修改先提交到master,cherr-pick到release分支
分支开发的的优缺点:
优点:1、不同功能在独立分支开发,消除了功能稳定前彼此干扰的问题 2、容易保证主干分支的质量,只要不把没有开发的特征分支合并入主干分支,主干分支就不会有问题的功能
缺点:1、不及时merge,特性分支合并到主干分支会比较麻烦 2、如果做CI/CD,需要对不同分支配备不同的构建环境