开发者社区 > 博文 > 利用CI机制管控jar依赖树
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

利用CI机制管控jar依赖树

  • 52****
  • 2023-08-09
  • IP归属:北京
  • 6400浏览

    1. 现状·问题

    你还记得你排查jar冲突的付出么?

    为了有效控制jar包更新带来的未知jar引入和变动,我们经常使用dependency-tree来查看依赖关系排查问题,通常是出现问题再被动分析和排查,此时人力成本是巨大的,同时系统已出问题,没有后悔药。


    2. 分析原因

    jar包依赖是异变的,且隐形的,jar冲突导致的问题经常发生,研发无法每次都关注其变化。


    3. 采取措施

    采用“敏捷”思想,小步走,每天定时监控jar包依赖关系的变化,让风险前置,主动显现出未知的问题。

    技术解决问题,CI/CD能力降低研发成本,每天23:00定时自动执行,All研发每天关注 jar doc change ~

    —— 我们将依赖树作为文件进行git版本控制,同时维护到CI上自动管控jar依赖关系的变更,这样可以即时发现依赖关系的变动。流水线定时每日触发扫描依赖树,保证每日最新,发现有变动即时发起doc变更,当研发关注到mr后,可以查看前一日是who改动了what,有效管理jar包。

    4. 实践步骤

    4.1 创建Makefile文件

    根目录:doc/dependency-tree.txt 空文件

    Makefile

    dependency-tree:
    	@mvn clean -U package -Dmaven.test.skip=true dependency:tree -Dverbose -DoutputFile=target/dependency-tree.txt --settings settings.xml
    	@grep -v 'omitted for' wms-outbound-web/target/dependency-tree.txt | grep -vw "tests" | grep -vw "test" | sed -e 's/TEST-SNAPSHOT/SNAPSHOT/g' > doc/dependency-tree.txt
    	@git add doc/dependency-tree.txt
    	@git commit -m "fix: [CI make dependency-tree]依赖树变更"
    	@git push origin HEAD:master
    
    

    settings.xml

    <?xml version="1.0" encoding="UTF-8"?>
    <settings
            xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"
            xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <localRepository>./maven/repository</localRepository>
        <profiles>
            <profile>
                <id>Repository</id>
                <repositories>
                    <repository>
                        <id>nexus</id>
                        <name>local private nexus</name>
                        <url>***</url>
                        <releases>
                            <enabled>true</enabled>
                        </releases>
                        <snapshots>
                            <enabled>false</enabled>
                        </snapshots>
                    </repository>
                    <repository>
                        <snapshots>
                            <enabled>false</enabled>
                        </snapshots>
                        <id>central</id>
                        <name>libs-releases</name>
                        <url>***</url>
                    </repository>
                    <repository>
                        <snapshots>
                            <updatePolicy>always</updatePolicy>
                        </snapshots>
                        <id>snapshots</id>
                        <name>libs-snapshots</name>
                        <url>***</url>
                    </repository>
                </repositories>
            </profile>
        </profiles>
        <activeProfiles>
            <activeProfile>***</activeProfile>
        </activeProfiles>
    </settings>
    
    
    


    4.2 修改gitignore文件

    .gitignore添加内容

    /maven


    4.3 配置bamboo

    选择定时触发的流水线(master流水线)配置

    在「下载代码」原子和「Maven构建」原子中间增加原子:「自定义脚本」(必须此顺序)

    Shell代码块:

    cd ${globalParams.system.APP_IDENTIFIER}
    make
    • 流程控制选择:失败继续(原因:CI修改代码需要mr评审,所以评审机制会导致push失败,无碍)


    4.4 配置coding

    增加xn_testdev_ci账号 master权限,同时增加到保护分支列表权限中



    5. 实现效果

    5.1 bamboo日志

    运行完毕可以看到日志success,push发起评审即可

    5.2 coding MR记录

    可以查看到bamboo账号「测试开发_持续集成」发起的mr,评审即可(只改动依赖树文件)


    6. 效能提升

    2021/10/19~至今,此实践 发现42次依赖变动其中7次发现了代码问题(研发已即时处理,否则每次未知的依赖变动都对应 >1 的研发成本)

    效能量化  模拟:2021/10/19~至今


    提效前(/人天)提效后(/人天)
    出现jar包冲突问题第1次2(今日发现,问题jar已引入半年之久,人力排查成本代价巨大)0.1(已前置发现异常并处理,早期成本代价极低,此冲突被避免)
    出现jar包冲突问题第2次2.5(明日发现,需要mvn依赖树一一排查,发现jar引入更早,成本更大)0.5(即时出现冲突,分析doc的git history直接定位引入变动)
    出现jar包冲突问题第3次3(多日后发现,问题jar已无法溯源引入时机,依赖关系混乱,只能研发互相询问,回忆)0.5(同上,doc git history定位引入变动)
    ..................
    出现jar包冲突问题n次以上,总成本计算>2*n<0.5*n



    7. 简要总结

    【jar包冲突】是每个code repo和每位研发的难题 !

    • 如果我们「可以将问题避免、可以将风险前置」,那后期「维护成本必然是降低的,日常效能必然是提升的」
    • 利用CI/CD机制,将jar包依赖树作为doc文件管控到git中,将每一次变动都记录快照,按照“敏捷”思想拆解迭代(周期是每天23:00定时)自动扫描依赖关系,最早发现最早处理,别再被动了,主动出击吧!