How exactly works build promotion with GitFlow?

I'm having a hard time understanding how exactly the concept of promoting builds (and their artifacts) works together with GitFlow. I'm in the process of working out a continuous integration/delivery workflow with Git, Jenkins and (as a new addition) Artifactory. This is what I have worked out so far:

Build artifacts from the develop branch will automatically be pushed to a dev repo (if unit tests etc. pass) and therefore promoted to a dev status. Further promotions are not possible for these artifacts.
Artifacts from feature branches don't get pushed or promoted at all.
Artifacts from the release branch can also only be promoted to dev (or should I introduce a release repo?)
As soon as release is merged into master, the new commit is tagged and Jenkins runs the full CI/CD pipeline. After unit tests and metrics (build stages which are run on all branches) the artifact is pushed to a master repo and promoted to master. Then the artifact is used for deployment to a staging environment, where final testing can be made (these tests can be automated in a full continuous deployment setup). If all tests are successful, the artifact will be pushed to a prod repo, deployed to production and promoted to prod status. If any stage until production fails, the tag belongs to a version, that never made it to production.

Is my understanding correct? I'm mostly confused about the master/release merging. Intuitively I would have said, that the binaries from release would undergo the most testing. However, GitFlow dictates that only commits on master get tagged (and I don't want to tag commits that technically did not produce the binaries which land in production). What if problems are found during the build of the commit on master? Is it "wrong" to have tags, which did not make it to production? Do I have to revert or undo the tag or even the merge commit?

It would be nice to hear other peoples approach to this build promotion + GitFlow thing. Any help is much appreciated.

Solution

There are so many different branching models, and so many people with their own takes, that I don't think there is a definitive reference on what "GitFlow" means. (Please feel free to prove me wrong, I love to debate this sort of thing).

With that being said, I (personally) find these two references to be very helpful, complete, and compelling:

So, what?

In my opinion, your first two points are correct and your last two points are wrong.

From a build promotion standpoint, all release and hotfix branches are eligible (and expected) to be deployed to your test/staging environment for final verification. From DataShift:

The code in the release branch is deployed onto a suitable test environment, tested, and any problems are fixed directly in the release branch. This deploy -> test -> fix -> redeploy -> retest cycle continues until you’re happy that the release is good enough to release to customers.

Then once everything has been verified and you're ready to release:

When the release is finished, the release branch is merged into master and into develop too, to make sure that any changes made in the release branch aren’t accidentally lost by new development.

Or, to summarize:

The master branch tracks released code only. The only commits to master are merges from release branches and hotfix branches.

Here is where it gets tricky and different projects have different opinions: where does the prod artifact actually come from?

As I see it, you have two choices:

Re-use the artifact from test/staging that was built from the release/hotfix branch.
Re-build the artifact from the commit in master.

From a code only perspective, these are equivalent - the code in master exactly matches the code that was just built and deployed to test/staging. However, from a build process perspective things might be different - different environment variables, different keys, etc.

Furthermore, things can be complicated with how your team views test vs staging.

So, what to do?

With the caveat that this is just my opinion and the assumption that staging means "production mirror", I think the following is a sensible process:

Feature branches are not deployed to a shared environment
The dev environment (if present) is built/deployed from the develop branch
The test environment is built/deployed from a release or hotfix branch
The staging environment is built/deployed from a release or hotfix branch AFTER normal testing/fixing has completed. NOTE: You could indicate this with an RC tag, but that's a team process question.
After staging verification is complete, the code is merged from release/hotfix to master and tagged with the release version.
The prod environment is deployed with the approved and tested artifact from staging.

Final thoughts:

GitFlow is a great place to start, but you're ultimately going to customize it for your own needs. Don't be afraid to say "this is what works for our team" and do it your own way - just make sure it's written down so everyone understands how you're doing it.