CODEWITHSUNDEEP
gitversion-control
Jan Schweiger
Jan Schweiger

Reputation: 23

Git: Maintain two versions with most features in common

My firm wants to maintain a SaaS version and an On-premise version of our product.

Most of the features are the same. Unfortunately, the differentiation cannot be done within the logic itself. Some code of the SaaS version should not be shipped with the On-premise version to the customer (for security reasons).

I am not sure how we can achieve this using git (or in our case gitlab). Maybe forking the SaaS version or using git's cherry-pick feature would work. I am still a git-beginner, so I am happy for any help. Thank you!

Upvotes: 1

Views: 67

Answers (1)

jessehouwing
jessehouwing

Reputation: 114641

Branching could be one way to maintain 2 similar but different systems, but it would mean that you're adding overhead and potential human errors to every change that is made.

Assuming most changes need to go into both systems, you want to to have a fully integrated core repository that contains this shared part. Optionally you could have separate repos for SaaS and on-prem specific parts, but I'd probably just put everything in a mono-repo, unless your product can be easily decomposed into multiple smaller pieces.

Now, you have many options to produce 2 different outcomes from a single repository, the simplest is to have 2 build configurations, one for the SaaS product, one for on-premise. You may want to have a packaging and distribution stage that runs after that build to take only the parts you need and generate the installer for the on-premise solution.

Many techniques exist to produce multiple outputs from the same source files, feature toggles, dependency injection, compiler directives, in-source attributes, conditions in your make/build script to include or exclude certain files from the build process etc etc etc.

There usually is a difference in the release process of the SaaS and the in-prem product, usually the SaaS product is on a faster release cadence and since you have full control over the installation, there may be less stringent requirements to that process. You usually only support one, maybe 2 versions of the SaaS product, (the one currently installed and the one you are rolling out next) while you may be supporting multiple versions of the on-premise product.

Microsoft's Azure DevOps is dealing with similar issues where the cloud product releases continuously, but their on-premise products only quarterly to bi-annually. They used a git process they called Microsoft Release Flow to manage the releases. That is documented here:

They are moving beyond this towards full CI/CD now, but I suspect this is interesting for you as reference.

Upvotes: 1

Related Questions