我们如何将Go Monorepo CI的构建时间减半

How We Halved Go Monorepo CI Build Time

Painting the Picture

描绘图片

Before 2021, Uber engineers would have to take quite a taxing journey to make a code change to the Go Monorepo. First, the engineer would make their changes on a local branch and put up a code revision to our internal code review system, Phabricator. Next, our infrastructure would see the request and initiate a number of validation jobs on our CI. Those jobs would run build and test validation using the Bazel™ build system, check the coverage, do some other work, and report back to the user a red light (i.e., tests failed or some other issues) or green light. Next, the user, after seeing the “green light,” would get their code reviewed and then initiate a “land” request to the Submit Queue. The queue, after receiving their request, would patch their changes on the latest HEAD of the main branch and re-run these associated builds and tests to make sure their change would be valid at the current state of the repository. If everything looked good, the changes would be pushed and the revision would be closed.

在2021年之前,Uber的工程师要对Go Monorepo进行代码修改,需要经历一段相当艰辛的旅程。首先,工程师会在本地分支上进行修改,并向我们的内部代码审查系统Phabricator提交代码修订。接下来,我们的基础设施会看到这个请求,并在我们的CI上启动一些验证工作。这些工作将使用Bazel™构建系统运行构建和测试验证,检查覆盖率,做一些其他工作,并向用户报告红灯(即测试失败或一些其他问题)或绿灯。接下来,用户在看到 "绿灯 "后,将得到他们的代码审查,然后向提交队列发起 "登陆 "请求。队列在收到他们的请求后,将在主分支的最新HEAD上修补他们的修改,并重新运行这些相关的构建和测试,以确保他们的修改在版本库的当前状态下是有效的。如果一切顺利的话,修改就会被推送,修订也会被关闭。

This sounds pretty easy, right? Make sure everything is green, reviewed, and then let the queue do the work to push your change!

这听起来很容易,对吗?确保所有的东西都是绿色的,经过审查,然后让队列做工作,推送你的变化!

Well… what if the change is to a fundamental and widely used library? All packages depending on the library will need to be validated, even though the change itself is only a few lines of code. This might slow down the “build and test” part. Validating this change could sometimes take several hours. Internally, we call such changes big changes

那么......如果改变的是一个基本的、广泛使用的库呢?所有依赖于这个库的包都需要被验证,即使这个改变本身只是几行代码。这可能会拖慢 "构建和测试 "部分。验证这一变化有时可能需要几个小时。在内部,我们把这种变化称为大变化

CTC: Changed Targ...

开通本站会员,查看完整译文。

Главная - Вики-сайт
Copyright © 2011-2024 iteam. Current version is 2.139.0. UTC+08:00, 2024-12-27 03:58
浙ICP备14020137号-1 $Гость$