-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Java build efficiency improvement suggestions #1936
Comments
优化1: 既然没有代码更新,为什么需要重新构建?什么样的场景? |
优化1的场景很明确,准确的说发生这种情况通常是指common项目(也就是如上的projectC),如projectA更新了,要发布对应的serviceA,但是projectC未更新,因此构建的时候无需构建projectC,只需构建projectA即可,这样就能节省很大一部分构建时间,加速很多了 |
不过到目前为止(1.14.0),虽然zadig没有专门对这种情况优化,但我已经在自定义构建脚本中实现了跳过构建,如下脚本我分享给更多有需要的童鞋: #!/bin/bash
set -e
cd $WORKSPACE/projectC/
# Enhanced check, skip current build step if commitId is not updated.
export COMMIT_ID="$projectC_COMMIT_ID"
export LAST_COMMIT_ID="$(cat $WORKSPACE/.projectC_LAST_COMMIT_ID 2>/dev/null)"
echo "The current commitId: $COMMIT_ID"
echo "The last commitId: $LAST_COMMIT_ID"
if [ "$COMMIT_ID" != "$LAST_COMMIT_ID" ]; then
echo "updated, new building ...."
mvn clean install -DskipTests -Dmaven.test.skip=true -T 2C
echo "Update the commmitId for $COMMIT_ID ..."
echo $COMMIT_ID > $WORKSPACE/.projectC_LAST_COMMIT_ID
else
echo "No update, using last build cache ...."
fi 注:要让如上增强检查有效,应该设置”缓存目录规则” 为 $PROJECT/$WORKFLOW |
对于优化2,实际上这种需求还是挺多的,原因倒是跟企业流程关系不大,主要是跟Java这门恐龙语言的工程化有很大关系(通常一个springboot服务构建发布都可能涉及几十个依赖项目),先抛开workflow间的隔离来说,如果是不同团队维护的,只要是共用一套zadig,从使用者的角度来说可以看成是一个黑合,他们如果每天构建n次,其中有m次发生时间有部分重叠,那就很符合这个情况,就可以让其后启动的build等待先启动的bulid把projectC完成(这里是阶段串行),然后分别继续并行构建……。 上面 @lilianzhu 提到的不同workflow 不好共享,这点我也基本认同,但我认为这是目前zadig对于这个实际需求的一个枷锁?反而还有很多时候如这里的serviceA、serviceB还是同一个团队维护的,为了多个微服务的接口发布一致性,必须同时构建发布,这就更加实用了。 |
情景:如果 projectA、projectB 都依赖 projectC,且这可能是分别两个团队在维护,
优化1:如果git pull发现未更新,则直接使用上次构建产物;
优化2:既然是多个团队维护且构建很频繁,若几边都在同时构建时,这样后触发的task,可以等待先触发的task把 projectC 构建完,然后再继续并发构建
总结就是:阶段性串行+阶段性并行,这类似于垃圾回收的加速算法
The text was updated successfully, but these errors were encountered: