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?
- The deployment from
masteris delayed and the feature is deployed first.
- The feature has to wait for a deployment from
masterbefore 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 (
3) show up live for 15 minutes and then disappear temporarily until they're redeployed from a
What happens if features
If I'm completely misunderstanding, could someone give an example of what happens if features
3 conflict with each other and an attempt is made to deploy them at the same time?