Close

基于主干的开发

了解为什么这种版本控制管理实践在 DevOps 团队中很常见。

Kev Zettler 头像
Kev Zettler

全栈 Web 开发人员


基于主干的开发是一种版本控制管理实践,开发人员将频繁的小规模更新合并到核心“主干”或主分支。由于它简化了合并和集成阶段,因此有助于实现 CI/CD 并提高软件交付和组织绩效。

在软件开发的早期,程序员可没有现代版本控制系统。相反,他们同时开发了两个版本的软件,以此来跟踪变更并在必要时撤销变更。随着时间的推移,这一流程被证明是劳动密集型、成本高昂且效率低下的。

随着版本控制系统的成熟,出现了各种开发风格,使程序员能够更轻松地发现错误,与同事并行编写代码,并加快发布节奏。如今,大多数程序员利用两种开发模式之一来提供高质量的软件——Gitflow 和基于主干的开发。

最初普及的 Gitflow 是一种更严格的开发模式,只有某些个人才能批准对主代码的变更。这样可以保持代码质量并最大限度地减少错误的数量。基于主干的开发是一种更加开放的模式,因为所有开发人员都可以访问主代码。这使团队能够快速迭代并实施 CI/CD

什么是基于主干的开发?


基于主干的开发是一种版本控制管理实践,开发人员将频繁的小规模更新合并到核心“主干”或主分支。这是 DevOps 团队的常用实践,也是 DevOps 生命周期的一部分,因为它简化了合并和集成阶段。实际上,基于主干的开发是 CI/CD 的必备实践。与其他长期功能分支策略相比,开发人员只需少量提交即可创建短期分支。随着代码库复杂性和团队规模的增加,基于主干的开发有助于保持生产版本的畅通。

Gitflow 与基于主干的开发


Gitflow 是一种替代的 Git 分支模型,它使用长期功能分支和多个主分支。与基于主干的开发相比,Gitflow 有更多、运行时间更长的分支和更大的提交。在此模型下,开发人员创建一个功能分支并将其合并到主干分支直到该功能完成。这些长期的功能分支需要更多的协作才能合并,因为它们偏离主干分支并引入冲突更新的风险更高。

查看解决方案

使用 Open DevOps 构建和操作软件

相关资料

如何实现持续集成

Gitflow 还有单独的主分支线,用于开发、热修复、功能和发布。在这些分支之间合并提交有不同的策略。由于有更多的分支需要兼顾和管理,因此往往会更加复杂,需要团队进行额外的规划会议和审查。

基于主干的开发要简单得多,因为它侧重于将主分支作为修复和发布的来源。在基于主干的开发中,假定主分支始终保持稳定,没有问题,可以部署。

基于主干的开发的优势


基于主干的开发是持续集成的必备实践。如果构建和测试流程是自动化的,但开发人员在孤立、冗长的功能分支上工作,这些分支很少集成到共享分支中,那么持续集成就无法发挥其潜力。

基于主干的开发缓解了代码集成的摩擦。开发人员完成新工作时,他们必须将新代码合并到主分支中。但是,在他们确认可以成功建造之前,他们不应将变更合并到主干上。在此阶段,如果从新工作开始以来进行了修改,则可能会出现冲突。特别是,随着开发团队的发展和代码库的扩大,这些冲突变得越来越复杂。当开发人员创建不同于源分支的单独分支而其他开发人员同时合并重叠的代码时,就会发生这种情况。幸运的是,基于主干的开发模式减少了这些冲突。

允许持续的代码集成

在基于主干的开发模型中,有一个存储库,其中有源源不断的提交流入主分支。为该提交流添加自动测试套件和代码覆盖率监控可实现持续集成。当新代码合并到主干中时,将运行自动集成和代码覆盖率测试以验证代码质量。

确保持续的代码审查

基于主干的开发的快速、小规模提交使代码审查成为一个更高效的流程。使用小型分支,开发人员可以快速查看和审查微小的变更。与长期存在的功能分支相比,这要容易得多,在该分支中,审阅者可以读取代码页或手动检查大面积的代码变更。

启用连续的生产代码发布

团队应每天频繁地合并到主分支。基于主干的开发努力使主干分支保持“绿色”,这意味着它可以在任何提交时进行部署。自动测试、代码融合和代码审查为基于主干的开发项目提供了保证,可以随时将其部署到生产环境中。这使团队能够灵活地经常部署到生产环境中,并为每日生产版本设定进一步的目标。

基于主干的开发和 CI/CD

随着 CI/CD 越来越受欢迎,分支模型得到了完善和优化,从而推动了基于主干的开发的兴起。现在,基于主干的开发是持续集成的必要条件。通过持续集成,开发人员可以执行基于主干的开发,同时进行自动测试,这些测试在每个提交到主干之后运行。这样可以确保项目始终正常运行。

基于主干的开发最佳实践


基于主干的开发可确保团队快速、一致地发布代码。以下是练习和实践列表,这些练习和实践将有助于优化团队的节奏并制定优化的发布时间表。

小批量开发

基于主干的开发遵循将代码交付到生产的快速节奏。如果基于主干的开发就像音乐一样,那将是一个断断续续的流程——短而简洁的音符接连不断,以存储库提交为笔记。保持较小的提交和分支可以更快地进行合并和部署。

几次提交或修改几行代码的微小变更可以最大限度地减少认知开销。对于团队来说,审查有限的代码区域与大量变更相比,进行有意义的对话并快速做出决策要容易得多。

功能标记

功能标记使开发人员能够将新的变更封装在非活动代码路径中,并在以后激活它,从而很好地补充了基于主干的开发。这允许开发人员放弃创建单独的存储库功能分支,而是直接将新功能代码提交到功能标记路径中的主分支。

功能标记直接鼓励小批量更新。开发人员无需创建功能分支并等待构建出完整的规范,而是可以创建一个主干提交,引入功能标记并推送新的主干提交,从而在标记中构建出功能规范。

实施全面的自动测试

任何打算实现 CI/CD 的现代软件项目都必须进行自动测试。有多种类型的自动测试在发布管道的不同阶段运行。短期运行的单元和集成测试是在开发期间和代码合并时执行的。运行时间更长、全栈、端到端测试将在后续的管道阶段针对完整的暂存或生产环境运行。

自动测试通过在开发人员合并新提交时保持小批量节奏来帮助基于主干的开发。自动测试套件会检查代码是否存在任何问题,然后自动批准或拒绝。这可以帮助开发人员快速创建提交并运行自动测试,看看它们是否引入了任何新问题。

执行异步代码审查

在基于主干的开发中,应立即进行代码审查,而不是将其放入异步系统供以后审查。自动测试提供了一层先发制人的代码审查。当开发人员准备好审查团队成员的拉取请求时,他们可以首先检查自动测试是否已通过以及代码覆盖率是否增加。这使审阅者可以立即放心,新代码符合某些规范。然后,审阅者可以专注于优化。

应用的代码存储库中有三个或更少的活跃分支

分支合并后,最佳实践是将其删除。不幸的是,具有大量活跃分支的存储库会产生一些不好的副作用。虽然通过检查活跃的分支来查看正在进行的工作可能对团队有好处,但如果周围还有陈旧和不活跃的分支,这种好处就会丧失。一些开发人员使用的 Git 用户界面在加载大量远程分支时可能会变得难以使用。

每天至少将分支合并到主干一次

高绩效、基于主干的开发团队应至少每天关闭并合并所有已开放且准备合并的分支。这个练习有助于保持节奏,并为版本跟踪设定节奏。然后,团队可以在一天结束时将主干标记为发布提交,这会带来每日敏捷发布增量加的好处。

减少了代码冻结和集成阶段的数量

敏捷的 CI/CD 团队在集成阶段不需要有计划的代码冻结或暂停,虽然组织可能出于其他原因需要冻结或暂停。CI/CD 中的“连续”表示更新在不断流动。基于主干的开发团队应尽量避免阻止代码冻结,并做出相应的计划,以确保发布管道不会停滞不前。

快速构建并立即执行

为了保持快速发布节奏,应优化构建和测试执行时间。CI/CD 构建工具应酌情使用缓存层,以避免对静态进行昂贵的计算。应该对测试进行优化,以便为第三方服务使用相应的存根。

总结...


目前,基于主干的开发是高绩效工程团队的标准,因为它通过使用简化的 Git 分支策略来设定和维持软件发布节奏。此外,基于主干的开发为工程团队提供了更大的灵活性,并可以控制他们向最终用户交付软件的方式。

Atlassian 的 Bitbucket 内置了 CI/CD 功能,支持基于主干的开发。立即试用

Kev Zettler
Kev Zettler

Kev 是领先的全栈 Web 开发人员和连续创业者,拥有十多年使用敏捷方法构建产品和团队的经验。他是 DevOps、加密货币和 VR/AR 等新兴开源技术的热情贡献者、作者和教育者。闲暇时,他会参加独立游戏开发活动。


分享此文章

推荐阅读

将这些资源加入书签,以了解 DevOps 团队的类型,或获取 Atlassian 关于 DevOps 的持续更新。

Devops 示意图

DevOps 社区

Devops 示意图

阅读博客文章

地图插图

免费试用

注册以获取我们的 DevOps 新闻资讯

Thank you for signing up