共计 2783 个字符，预计需要花费 7 分钟才能阅读完成。
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 转载请注明出处
