Build once, deploy many using gitflow and gitversion

Question

The gitflow fits our needs and the giversion seems to be fitting the gitflow. But there is one thing which I don't fully understand. Let me explain what bothers me.

1. We do work on some functionality on develop branch - all the packages are marked like this 1.3.0-unstable.1, 1.3.0-unstable.2 and so on.
2. Every package is going though the pipeline - dev, test, uat, prod.
3. So when the dev is ready and everything is good, according to the gitflow we start the release branch.
4. No changes need to be done on release, we are finishing it right away - release branch merged into the master and into the develop.
5. Build server creates one more package 1.3.0 which is kind of prod ready.

How to achieve build once, deploy many here? According to all the rules, we need to promote 1.3.0-unstable.x to the prod env, cause exactly this package was tested in dev and test, but the version looks a bit strange for prod, isn't it? When 1.3.0 which came from master branch was never deployed anywhere.

Question is similar to this: In the git flow model should I build from the merge commit in master to release?

The answer is not really satisfying:

1. We do -no-ff while merging to the master
2. It's still a different package

Answer 1

Let me answer this question myself. We came up to the point where we realised that supporting several versions/several environments using the gitflow is a huge burden. Hence we were looking for something simpler, which is github flow. Of course it didn't completely solve the original issue(build once - deploy many) for us, but this is how we partly solved it.

Our pipeline changed

from: dev -> test -> uat -> prod

to: dev -> test and then uat -> prod

So like I said before, we are using the github flow. Whenever we are working on the new feature, first - we create a branch featurename from latest master. Every build from this branch is versioned like this 1.3.0-featurename.1, 1.3.0-featurename.2 and so on.

Once developer finishes his implementation and does all the dev checks, these exact binaries go to the test environment for QA. After QA guys sign off this version, we are happy to push this through our second pipeline uat -> prod. We merge the pull request for the featurename branch and the build version we get afterwards, lets say: 1.3.1 goes to the uat environment. Once it's signed off there, we push exactly the same binaries to the prod environment.

If there were several feature branches being developed at the same time, the next version we push to the test environment supposed to be rebased on top of the latest master and again through the pipeline.