social.zlatko.dev

#askFediverse Anybody has any handy links on versioning SaaS software? As in, splitting off different versions for particular customers and "freezing" those versions for those customers, while working in a CI/CD way for everything else? I want to look into feasibility of such things like plugins, splinter code bases or parts of and similar approaches before I can confirm what I already said when they asked me (which was "no way")?

@zlatko@social.zlatko.dev Unless you've got a compelling need specifically to lock in versions rather than feature sets, I'd go with a feature flag setup instead. All users access the same version of the application, but some of its capabilities are hidden from certain users, in a way that can be independently configured.

That said, I don't know what problem you're trying to solve, so maybe that kind of versioning is the way to go after all. Life is full of weird situations requiring weird responses. If you're absolutely sure this is what you need, then, basically, treat the older version as a separate product. Duplicate all the infrastructure, including most importantly having separate instances of data stores and caches. Create a second trunk-like branch in the source repository for this old version (or it may be simpler to just fork the repo) and duplicate the CI/CD as well. Users who are meant to use the old version will visit a different URL, and the traffic to that URL would be balanced among a different set of application instances. If the same user needs to be able to log into multiple versions of the application, then you'll need some sort of single sign-on to go with it, if you don't already have it.

The reason for doing it this way is because: fundamental to the way SaaS products work is that the current version is the one users access, period. If you want to contradict that premise by having multiple versions live at the same time (and not just temporarily running two consecutive versions because of a rolling deployment or something), then you need to create as much distance as possible between them, in order to counteract the tendency of all the SaaS design elements you're already following to drag your system design back towards its natural single-version state, introducing difficult-to-manage complexity as the concept of a "version" gets coupled to other concepts in the system.

It'd be a pretty heavy lift to set all that up, but that's the only way I see to keep it clean and manageable. Avoiding that trouble is why I suggest using feature flags instead.