CI/CD and versioning workflow with multiple environments and versions

Hello!

I'm interested in hearing about the different kinds of CI/CD workflows you all might have. At work, we've ran multiple times into the same problem. Here's a brief overview of our workflow currently:

• All branches are generally branched from our devel branch (e.g. feature/<ticket-no>-some-feature), and merged to the devel branch.
• When creating a release, a branch (e.g. version/1.0.1) is branched from the develop branch. Version number updates, release notes etc. are committed to that branch, and then the branch is merged back to devel. Then devel is merged to master (which should follow our current production version), and then a new tag is created from master with a version number which matches the version branch. From there the deployment is pretty much automated, pipelines will create a package from the system which is deployed to one of our environments.
• Our newest features are deployed to our experimental environment from the devel branch by creating a tag from there. No problems there, since when creating a release to our experimental env, we can just deploy whatever is in the devel branch.

The problem we're facing constantly, is that since we've basically 3 different environments (which are essentially staging/experimental/production) with different versions, creating patches to the production environment is a bit annoying if it's much behind our current devel branch. Lets say that:

1. Production is running version 2.3.5
2. Experimental is running version 3.1.2
3. A bug is found in the Production environment and also exists in the experimental environment. We create a bugfix branch from devel, fix it and merge it to devel, but since it's not a very fatal bug and it relies on some other component which needs fixing, we won't deploy it right away
4. We continue pushing features to devel and fixing bugs that we might find. Since we've pushed features between fixing bugs, some of the bugfixes at some point might start relying on some feature changes.

Then it's time to create some releases! Creating a release to Experimental is simple, just create a new version from devel, merge it to devel and create a tag from it. Easy peasy. However, creating a new release to Production is not that simple, if we simply want to include the fixes in the Production release (and not the feature changes). Right now we've just cherry-picked the merge commits which we want to include to the Production version branch, and then merged the branch to master and created a tag from it. But it often creates some annoying (though not unresolvable) merge conflicts, because at some point some feature between bugfixes made the bugfix reliant on one of the feature commits. Also when it's time to push all changes in the Experimental to Production, due to the merge conflicts etc. the commit history is all weird and just force pushing devel to master is very tempting, but not very satisfying.

How are all you handling versioning, integration and delivery in your projects? While writing this I realized that maybe one way to solve the problem would be to always create the bugfix branches from master if the bug exists in Production environment already. Then we could merge the bugfix to master (instead of devel) and rebase devel on top of that right away. Does it make sense?