由jenkins打包过程优化引发的思考前言本文正在参与 “性能优化实战记录”话题征文活动最近在做jenkins打包设

前言

本文正在参与 “性能优化实战记录”话题征文活动

最近在做jenkins打包设置时，发现在构建时每回都会执行npm install。即使在工作区内缓存有node_modules时，也会执行检查包的操作。看下面的结果：在检查1643个包，花了将近10s钟的时间.对于测试环境频繁修改bug要更新环境的我，这个怎么能忍，于是边查shell（不经常用）边修改，利用缓存成功解决了问题。

思路

在jenkins构建环节中，先检查工作区内是否有package.json的hash缓存，如果没有就新建一个，并更新

funmd_1() {
echo "更新旧文件"
find . -maxdepth 1 -name "package.json" | xargs md5sum > ./funmd_1.log
}
if [ ! -f ./funmd_1.log ];then
funmd5_1
//更新函数
npm isntall
update
fi

这里注意两个问题：

maxdepth 1指令表示只搜索当前目录下的文件，如果不用会递归搜索node_modules下的package.json.
这里采用md5sum对文件内容做hash，因为如果文件内容比较大的话，后续直接做diff效率相对较低.

如果旧hash存在就比较做新旧比较如果有改动就npm install并更新。修改下之前的逻辑

funmd_1() {
echo "更新旧文件"
find . -maxdepth 1 -name "package.json" | xargs md5sum > ./funmd_1.log
}
funmd_2() {
echo "更新新文件"
find . -maxdepth 1 -name "package.json" | xargs md5sum > ./funmd_2.log
}
if [ ! -f ./funmd_1.log ];then
    funmd_1
    funmd_2
    npm isntall
    #这里更新函数自己定义
    update
else
    funmd_2
    diff ./funmd_1.log ./funmd_2.log
if [ $? = 0 ]; then
    echo "未修改依赖"
    mian_task
else
    echo "修改依赖"
    npm install
    update
    funmd_1
fi
fi

这里还留了个小坑，你linux下跑这个代码在diff ./funmd5_1.log ./funmd5_2.log是会报UNEXPECTED OPERATOR的错误，这是因为调用的是dash，我们需要在最前面加上#!/bin/bash即可。

展开

关于jenkins打包其实最影响性能的还是构建过程，如果你项目是巨石应用，你可以通过联邦模块（想了解的可以看这篇架构之路-你不知道的模块共享）将应用拆分，将几乎不会改变的模块抽离出去，从而减少打包代码，加快打包速度。

总结

在编码的世界中，缓存无处不在，无论是react中的对象池概念，还是v8的内联缓存，无不是通过缓存大大的提高生产效率。在你们的工作中运用了哪些缓存的技术呢？欢迎大家留言讨论。

公众号:胡哥教你学前端

掘金号：Breeze同学