3 ms·

Can you explain to me how you'd avoid having said separate codepaths and tests in a multi-repo situation? You'd still need to update the server to support both

Can you explain to me how you'd avoid having said separate codepaths and tests in a multi-repo situation? You'd still need to update the server to support both API versions during the transition period. We agree the change can't be made atomically in a monorepo, but it also can't be done atomically in a multi-repo environment. So, since you have two code paths in prod, you also need them in your tests. It's a manual process either way, and completely independent of your vcs.

lmm 5y ago
Say you currently have server version 5 and client version 3 deployed. You've already tested those. Now you make a change to the shared protocol, and you decide you're going to deploy the server first and then the client (or vice versa). So you bump the server version to 6 in your integration tests, check if they pass, then deploy server version 6 (progressively, but that's fine, you've tested both the combination of client 3 and server 5 and client 3 and server 6). Then you bump the client version to 4 in your integration tests, check if they pass, and deploy client version 4. Importantly, this is the completely natural way to do every release and deploy; you'd have to go out of your way not to do this. Even if you thought version 6 didn't contain any protocol changes, you'd still deploy it exactly the same way. So you end up testing the real combination of code that's about to get deployed, before you deploy it, every time.