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 定时）自动扫描依赖关系，最早发现最早处理，别再被动了，主动出击吧！

作者：京东物流 周奕儒

来源：京东云开发者社区 自猿其说 Tech 转载请注明出处