[pjmlp]

I can assert that from what I have seen during the last 30 years, I rather bet on multi-repos and binary libraries than monorepos.

The processes you describe are great to make teams think twice how to go at a change, instead of "let's change everything and see how it goes" attitude.

[samsquire]

That time spent thinking of how to plan a change goes away when you have a monorepository. You literally don't pay that cost as you can work out the change fully locally.

I built a tool to bring up every microservice locally so you could test every change together so the separate repository problem went away. It coordinates vagrant LXC environments.

The version I built at my employer was integrated with chef and Ansible. The version I built at my employer handled cloning and pulling dependencies too. And could build in parallel and deploy to local load balancer haproxies.

But my open source version is barebones by comparison. In the future I shall try build developer tools open source rather than trapping work at my employer.

HTTPS://GitHub.com/samsquire/platform-up

[charcircuit]

>That time spent thinking of how to plan a change goes away when you have a monorepository

Not entirely. Since the fleet isn't atomically updated to the next version you have to be careful about multiple versions being compatible with each other.

[samsquire]

Upgrading software and Postgres databases is a difficult problem in general.

The text itself can be changed but it takes at least 15 minutes to mutate to a deployment. We still cannot generically mutate running code to other running code. Ksplice and other live kernel patching and Chrome's binary patching should be generalised and productised.

Patching methods at runtime is another thing that is possible (ruby, python and Erlang) but I am not aware of a general framework for deploying mutations to servers at runtime.