You probably use Semantic Versioning for tags and you should not deploy master branch

[AhtiAhde]

I believe you are probably using Semantic Versioning when you create tags. This would be nice thing to mention (how to name your tags).

You should always deploy from detatched heads (tags/commits instead of branches, which have history that can move), because this creates certainty to the deployment process (deployment with static commit hashes, instead of dynamic branches).

Also in robust systems, you should be able to run certain front-end servers with tags of next release and others with the previous release tag; this way your developers can test the actual servers and you can use load-balancers to direct only part of the visitors to the new release.

e.g. When Netflix releases a new version, only 5% of the users are redirected to the cluster which has the new release and rest of the users use the reliable version of Netflix. This way deployment doesn't create cascading problems.

Of course this is a bit too robust for non-critical systems, but the practice of Semantic Versioning and releasing tags instead of branches is easy to adopt, and when things get critical, you are ready.

Hopefully I expressed the ideas clear enough, I am in a bit of hurry at the moment. Hope this was helpful!

[tharna]

Thanks for your feedback, very good points there.
Tagging and deployment strategies is a layer I consider being on top of the workflow layer, so that it can be adjusted to suit the need of the project. E.g small projects deployed only to single server don't need such complex solutions as the sites that run 10s or even 100s of servers.

There are also some Paas providers that only support releases from branches so using tags to deploy might always even be an option.

For the large scale zero-downtime deployments with active development cycle deploying tags is definately the best suited option.

Semantic version is pretty close match for what I have been thinking for the preferred tagging schema. Versioning should be pretty straight forward to follow branch sturcture in a way where there would be one additional version part:
First being the MAJOR, but this is depatable as usually projects moving up vit major versions are usually complete rewrites so this wouldn't change during the entity lifetime, so basically this could be left out in favour of adapting the semantic versioning more closely.
Second part, MINOR could be in par with the epic branches, so any time a epic branch is merged ther ewould be MINOR versoin bump. Loosely this could also be used with bigger releases consisting of non-related normal feature branches.
Next part would correspond to any new feature an dlast part with hotfixes.

But in the end the versioning should be considered more in the light of the project in question to correspond more closely to what is appropriate in that context.

[AhtiAhde]

The workflow with PaaS is that you should have deployment branches separate from release branches where you do pull requests upon upgrading the release version. This way you get easy revert mechanism to previous stable release.

Other than that fair points.