We write software that lives in a git repository. We've sold this software to several companies. Each company has a virtual machine running one or more instances of our stuff inside their internal networks.
We currently use git bundles to push code updates out to remote servers for replication. (lots of these servers are behind enterprise firewalls so we have no better option for direct git communication)
That all works fairly well and simply.
On paper...
What actually happens though is that in order to update instances of our software, we have to pass local validation processes at each enterprise where we run. What that means in practice is that we seldom are able to run a production instance of our software on the absolute latest master release of our product in git.
So.. the "obvious" solution (we think) is a gitflow-esque method where we "simply" have multiple release branches, each corresponding to an actual running production instance of our software. This would allow us to have multiple instances each running disparate versions of our stuff all with different levels of hotfixes and whatnot as needed.
I put "obvious" and "sipmly" in quotes in that last paragraph because this solution doesn't seem to be either of those things. It seems rediculously cumbersome to have multiple release branches while trying to maintain what features and hotfixes are propogated to each one. Say we write a hotfix, do we then script up something to merge that hotfix into 50 'release' branches for distribution? That stinks right?
My question then is... what other solutions or recomendations might exist to solve this problem? I've heard rumbles of things called "continuous delivery" and "continuous deployment" software suites. Is that the world we need to be looking into to solve this problem for us? I think my real question here is whether solutions to this problem exist and what these solutions are called so I can direct my googles.
