How can we release features to preproduction and also work on production fixes

[rajkumar79]

Lets assume that we have released build version 1.0.0 to production.

Now we need to work on features A,B,C and D and we create four different branches.

Feature Set Team A completed the feature and want to release code to a pre-production environment.

So they merge branch A with master and create a release artifact and they ship it to a pre production environment.

Now we have a production issue but the master has the feature Code A,

How can we resolve this?

[schrags]

You could create a fix branch pointing to the production release SHA, add your changes, deploy, and merge back into master.

[jaw6]

So, I want to translate a little of what's going on into git commands:

git tag 1.0.0
git push --tags
git checkout -b featureA
[ work happens here ]
git push -u origin featureA
[ pull request is merged, master now has featureA ]

In the scenario here, at this point, some issue is discovered in production (which has 1.0.0, not master) and we want to fix that issue but we're not actually ready to ship featureA (even though it's been merged to master).

First: we usually recommend (eg, in GitHub Flow) that master always be "deployable" -- there's nothing special about the master branch name, but it's something of a convention to leave that branch as representative of "currently in production" and/or "deployable to production at any time" -- if that's not what it means in your environment, you might want to explore other names that more accurate represent what's happening in your environment.

In other words, this scenario is easier to manage if you have some other non-master branch designated as your "pre-production" environment (teams usually call these branches dev, release-candidate or next) -- but mostly because master tends to mean "production ready".

But: how to deal with this scenario as is? It sort of depends on how your team feels about featureA -- was merging that to master a mistake? (Are we potentially mis-representing it as "production ready" when it actually needs more testing?) If that's the case, you should revert the featureA pull request: master goes back to "production ready" status, and work can begin on the new fix based on master.

On the other hand, let's say master == pre-production is fine in your environment but we still need to get a fix out for 1.0.0 ... In that case, we'll want to change the "base" for the new fix branch like so:

git checkout -b fix 1.0.0

There's still some ambiguity here -- where should the fix branch go when it's ready? We want to merge it and tag it as 1.0.1, but, currently, master means "pre-production" -- we don't want to send featureA out as 1.0.1. Again, much of the "messy" feeling here is because we've "overloaded" the semantics of master -- we want it to mean two things at once, both "production ready" and "pre-production testing" -- but we have a couple of options. We can, for example:

git tag 1.0.1 fix

Again, this is potentially messy (we need to be careful about our version counting, careful to ensure that all fix branches are merged to ... somewhere) but all of this "mess" is avoidable/fixable by designating some branch as "what's currently considered production" (again, conventionally master but you could have production or whatever you like) and avoid merging/revert anything that isn't really production ready.