Can features deployed with GitHub Flow disappear from production?

Question

I'm trying to get a better understanding of Git workflows and read this blog post. What happens after a merge to master if another feature is waiting to deploy?

1. The deployment from master is delayed and the feature is deployed first.

2. The feature has to wait for a deployment from master before being allowed to lock the application.

That blog post says:

Once a commit on master has been deployed to production, it should never be “removed” from production by deploying a branch that doesn’t have that commit in it yet.

The above suggests master may have commits that haven't been deployed yet.

An endpoint on the github.com application exposes the SHA1 that is currently running in production. We submit this to the GitHub compare API to obtain the “merge base”, or the common ancestor, of master and the production SHA1. We can then compare this to the branch that we’re attempting to deploy to check that the branch is caught up. By using the common ancestor of master and production, code that only exists on a branch can be removed from production, and changes that have landed on master but haven’t been deployed yet won’t require branches to merge them in before deploying.

If deployments from master always took precedence, the "merge base" would always be HEAD, so, again, it suggests there can be commits on master that haven't been deployed.

Both of those lead me to believe deployments from commits on master can be delayed while additional features get deployed / tested on production first. If that's the case, do both features (2 and 3) show up live for 15 minutes and then disappear temporarily until they're redeployed from a master commit?

What happens if features 2 and 3 conflict?

If I'm completely misunderstanding, could someone give an example of what happens if features 2 and 3 conflict with each other and an attempt is made to deploy them at the same time?

Answer 1

In the GitHub Flow, a branch is deployed before it is merged into master. Thus, master represents the history of successfully deployed versions.

In the article you linked, GitHub the company explains how they address two huge problems with this workflow:

• How can I prevent two branches from being deployed at the same time?
• How can I prevent a branch from being deployed if it isn't up to date with master?

The solution they arrive at uses external tooling, not any Git functionality. Their deployment tooling can lock deployments for one branch, so that conflicting deployments are prevented.

Their solution for deployed branches being up to date is more tricky, because they seem to allow merges into master without having deployed them first. Instead, they apparently have a concept of a production branch for commits that were deployed. A branch should not remove commits on master that were deployed, i.e. any branch that is to be deployed must contain the merge base of the current production and master. I assume the branch being deployed them becomes the production branch? Their blog post is not entirely clear.

In your scenarios, once the first feature branch / the current production branch is merged (creating merge commit #4), the merge base of master and production is the HEAD of the production branch (#2). Therefore, the other branch can only be deployed if it contains #2, such as by merging or rebasing on #4 prior to starting the deployment. So your second diagram seems to be closer to their approach. Note that the merge commit #4 does not have to be deployed immediately, since it contains no changes relative to the production branch.

However, none of these details are core to the GitHub Flow, and you can certainly do continuous deployment without the GitHub Flow. For example, passing a plush toy around as a lock can be an effective non-technical solution to the locking problem, at least for small co-located teams. Deploying from master instead of from feature branches completely avoids the regression problem. It also makes experimentation in production more difficult, which might actually be a feature?

So please don't copy any workflow just because someone famous has developed enough internal tooling to make this workflow not suck. Instead, do something that makes sense under your circumstances, and solves your problems.