8

The accepted answer to "What are possible implementations (or examples) of the four-eyes principle?" suggests that GitHub's Pull Request model is a possible implementation.

And my own answer to "How to implement the four-eyes principle for emergency fixes?" explains the concept of post-approvals.

My question: Can GitHub's Pull Request model be used for implementing post approvals also? If so: how? If not, is there anything else in Git (GitHub?) that I could use for it?

Improve this question
4
  • Does the description of Chef's Contribution Process makes sense ? quoting it with a link would be plagiarism, and I don't think I will add anything on top of tip.
    – Tensibai
    Mar 27, 2017 at 7:57
  • Bonjoiur @Tensibai ... I don't understand how that process could be used/considered for such post approvals (must be me who doesn't get it). So maybe you should add an answer (with reference to that link), and add an explanation why you think such process does answer my question?
    – Pierre.Vriens ♦
    Mar 27, 2017 at 8:17
  • I assume I'll be repeating a bunch of what Richard's already said. The main point is the maintainers have a right to merge in master, so they can follow the same scheme, approving their own work and still being able to review it later.
    – Tensibai
    Mar 27, 2017 at 8:46
  • All in all, this is the Github way to set in place your answer linked in your question :)
    – Tensibai
    Mar 27, 2017 at 12:08

1 Answer 1

Reset to default
4

Yes, I do believe so. To explain that I need to lay some groundwork on how I have implemented something similar, I have simplified the model in an attempt to make it as clear as possible.

Assumptions

I am making the assumption here that Jenkins, TeamCity or similar is being used as the CI/CD tool of choice. Additionally GitHub is being used and that there is a well-defined and appropriately controlled branching structure:

Branching Diagram

Configuration

In this example, GitHub is configured as follows:

  • The Black 'Master' branch can only be merged into using Pull Requests, direct commits are disallowed.
  • The Blue 'Development' branch can accept direct commits or merges; in practice, there may be additional restrictions on this branch.
  • The Red 'Hotfix' branch can accept direct commits and merges.
  • Required Status Checks are enabled in strict mode to prevent pull requests merging when the branch is failing the build.
  • If the Hotfix branch is ahead of Master then pull requests into Master will be blocked, either with the Status API or the Pre-Receive Hooks on GitHub Enterprise.

The CI/CD tools are configured as follows:

  • Builds from the Development branch cannot be deployed to production.
  • Builds from Master can be deployed to all environments.
  • Builds from Hotfix can be deployed to all environments.
  • Deployments from Hotfix will notify some non-development function, for example, the Change/Release team and ask them to perform the post-approval.

Notes

Master is protected as it represents the current state of production, to do this practically you may have another "Release" branch that deployments are made from and only when successful merge into the Master branch.

Key Points

The Blue Development branch is basically a free-for-all. Hotfix is kind of a free-for-all but any deployments trigger a type of Break Glass by notifying a non-development function who will perform the post-approval and in the process will merge the change into Master.

It's essential merges into Master stop while Hotfix is ahead of Master to:

  1. Prevent a deployment from Master overwriting the Hotfix, which could result in an regression.
  2. Prevent a Hotfix sitting in the Hotfix branch languishing without being merged in.

In some organisations it may help to prevent all pushes to the central GitHub repository while a Hotfix is pending post-approval.

Improve this answer
3
  • Nice Richard, merci! I'm going to digest a few of the things you wrote in your anwer, and possibly add some extra comments later on to clarify/complete a few things you wrote about. Where appropriate I might add followup-question(s) also. Are familiar with somthing like "the answer to a question triggers 10 new questions ..."?
    – Pierre.Vriens ♦
    Mar 26, 2017 at 18:05
  • @Pierre.Vriens please do ask plenty of questions, I've effectively extracted the above out of a client's implementation of GitHub Enterprise and Jenkins and entirely from memory - it is possible I have missed something, it did take me 4 hours to write it as I was checking very carefully. As to "the answer to a question triggers 10 new questions" it's very common in consulting.
    – Richard Slater
    Mar 26, 2017 at 18:40
  • Did you ever get a chance to get the questions down on "paper"? Happy to talk over it in chat if you prefer.
    – Richard Slater
    Apr 3, 2017 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.