化繁为简的企业级 Git 管理实战(二):多分支子模块持续集成

2016/04/21 19:30
阅读数 56

author:潘伟洲

需求描述

在 上一篇文章 中,我简单描述了我们一个项目的复杂程度:子模块、嵌套子模块、多分支。除了工程分支切换上的复杂,我们还遇到另一个问题:子模块持续集成。

主工程持续集成

先说说主工程如何做持续集成。我们使用 Gitlab 自带的 Gitlab-Ci 作为我们的持续集成系统。Android 端的主工程的持续集成脚本如下:

build:
  tags:
    - android
  script:
    - ./fmanager checkout -f $CI_BUILD_REF_NAME
    - ./fmanager update
    - gradle clean
    - gradle aR

其中, CI_BUILD_REF_NAME 指定要编译哪个分支的主工程。当我们推送代码到某个分支时,该分支下的持续集成脚本就会被调用,CI_BUILD_REF_NAME 变量就会是那个分支的名字。在执行构建前,先用 fmanager 完成主工程和所有模块的分支切换 ,之后再用 fmanager 更新整个项目的代码。最后再执行编译指令。

主工程的持续集成就是这么简单。然而这远远不能满足我们的需求:我们的工程有多个子模块。一个子模块的某个分支可能被多个父模块的多个分支依赖。例如,common 模块的 master_dev 分支可能被 framework 模块的 master_dev、jilin_dev、taishan_dev 分支依赖。在这样的情况下,任何一个子模块如果不注意提交前自测,都有可能导致多个分支的整个工程编译失败,阻塞多个分支的开发进度。比这更困难的是,对某个模块的修改也许可以保证在当前主工程分支上编译通过,但却意外导致了另外一个依赖该子模块的主工程分支的编译失败。

因此,我们除了要对主工程进行持续集成测试之外,也不得不对子模块做持续集成测试:任何一个子模块某个分支一旦推送了代码,就触发所有依赖它的主工程的分支的持续集成测试。为了实现这个目标,我们尝试了三种方案。

温馨提示:请单击右下角的 [阅读原文] 阅读完整文章。


本文分享自微信公众号 - HaHack(gh_12d2fe363c80)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
0
分享
返回顶部
顶部