[throwaway315724]

> I'd love if someone still working there were to write a nice post about that system, it was the first of such a kind I saw.

I don't know how far back you saw the Bloomberg system, but at this point it's basically the same as the Debian system (as in, debian/ subdirectories, .deb files, etc.). Versions of git projects are published as tarballs (source packages). Then sets of published projects are "promoted" and all projects that transitively depend on them are rebuilt and unit tested in a sandbox environment. If that process fails, the promotion fails.

Each source package can use any number of build systems, implementation languages, or project structures.

There's also a legacy subversion monorepo with a monolithic build system that builds on top of that, but it's slowly being phased out.

All that is an integration build including thousands of discrete projects. Those projects typically have additional CI/CD enrollments outside of the integration build system too.

[MakersF]

This is what I saw. But I think it would be good to share the experience of a big, mature company with it to show that it's a system that can work, and can be easily added to companies which currently have a multi repo approach.

Also, there are quite a few tools to manage the distributions, and it would be great if they were open sourced. Basically Bloomberg championing their approach, to gain the usual advantages of open source (developer familiarity, cooperating across companies for improvements, and so on)

> Those projects typically have additional CI/CD enrollments outside of the integration build system too.

Another thing to call out is that you can simulate the "promotion", so you can check in your PRs whether your change is going to break any dependency or dependant.