5 ms·
In what way is Google an exception? Are you saying that only one or a small number of different binaries run on Google's production servers? Google famously ha
by closeparen 5y ago
In what way is Google an exception? Are you saying that only one or a small number of different binaries run on Google's production servers?
Google famously has a monorepo but that's different from a monolithic service architecture.
- jedberg 5y agoYes, that is a fair distinction that I simplified over. You don't really get a lot of the gains of microservices if you're using a monorepo, so while they do have multiple binaries/services, you still have to check into a single repo and wait for all the tests/etc. To be fair I haven't visited Google in a while and maybe it's changed now, but at least decade ago it was very different from how everyone else did microservices.
- singron 5y agoEach releasable unit can wait for whatever tests you want. Usually it's just the tests for that unit. Google is actually a good example of why monolith/microservices is a completely different concept to monorepo/multirepo. I.e. you can put your monolith in multiple repos, and you can put 100,000+ services in 1 repo.
- eweise 5y agoThe past few companies I was at, we discussed whether we wanted a single or multiple repos. But that was a separate conversation from microservices, so I don't think its unusual to have a monorepo with microservices.
- timmg 5y ago> You don't really get a lot of the gains of microservices if you're using a monorepo I think the two are completely orthogonal. At Google, when you check in code, it tests against things it could have broken. Not all tests in the system. For most services, that means just testing the service. For infrastructure code, then you have to test many services.
- jedberg 5y agoIt seems things have changed since I last looked at how Google does deployments. Back then, every test ran on every checkin to the mainline, and all code was checked into the mainline. It even talks about that in the Google SRE book.
- timmg 5y agoI've been at Google for almost 12 years. It's been this way the whole time I've been there.
- cmckn 5y agoI think you were misunderstanding something. Why would every code change cause a compile and test across the entire company? That is to say; not only does that not scale, it’s totally unnecessary*. Only the downstream consumers of a change are rebuilt and tested, like you’d expect (see: bazel and the monstrous makefile before that). In this sense, the fact that Google uses a monorepo is mostly an implementation detail. It has some impact on the company’s workflows and tooling, but not its software architecture. * unless you’re changing a very common dependency, of course, and Google has tooling for this.
- lupire 5y agoEven if that were true (and it is not true), the non-dependent tests would finish in zero time because the results are cached and hashed by dependency tree.
- jedberg 5y agoI assumed that was always the case and why it made sense that they run all tests.
- ithkuil 5y agoHermetic builds allow you to cache your builds and your test executions in such a way that running all builds and all tests for every commit is indistinguishable from executing only the builds and tests that you could have affected
- deleted 5y ago[deleted]