[boris]

There is a parallel with database transactions: it's great if you can do everything in a single database/transaction (atomic monorepo commit). But that only scales so far (on both dimensions: single database and single transaction). You can try distributed transactions (multiple coordinated commits) but that also has limits. The next step is eventual consistency, which would be equivalent to releasing a new version of the component while preserving the old one and with dependents eventually migrating to it at their own pace.

[jacobr1]

This is why in microservice architectures you try to have data stores encapsulated via each service. So the APIs can support some kind backward compatibility path as you roll out changes to clients that interact with the service (presuming the db migration has public API implications).

[awesome_dude]

Doesn't that rely on the code being able to work in both states?

I mean, to use a different metaphor, an incremental rollout is all fine and dandy until the old code discovers that it cannot work with the state generated by the new code.

[stetrain]

Yes, but depending on the code you’re working on that may be the case anyway even with a monorepo.

For example a web api that talks to a database but is deployed with more than one instance that will get rolling updates to the new version to avoid any downtime. There will be overlapping requests to both old and new code at the same time.

Or if you want to do a trial deployment of the new version to 10% of traffic for some period of time.

Or if it’s a mobile or desktop installed app that talks to a server where you have to handle people using the previous version well after you’ve rolled out an update.

[immibis]

Yes, it does.