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

Painting the Picture

submited by
Style Pass
2022-06-24 05:00:06

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.

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

Leave a Comment