<p>One of the implementation on code is the <a href="https://help.github.com/articles/about-pull-requests/" rel="noreferrer">Pull Request model</a> (PR)  popularized by GitHub.</p>

<p>The main reasoning behind is that only a small set of maintainers of the product will be allowed to merge code into the release branch. Every new feature/bugfix will happen on a new branch and once done will be defined as a pull request.</p>

<p>This allows to test on the merge from actual release (master) code with the code in the PR in an automatic way (Travis being the most popular for public project actually) and give a first feed back on the code quality. Travis CI (for example) can run on the result of actual master with the  code from the pull request merged into it, so it will fail if the merge is impossible, or if the commands defined in the travisci.yml return a non zero exit code</p>

<p>Once the automatic tests have passed, for the 4 eyes principle, it still requires a configurable number of persons to review and approve the change before it gets merged obviously at least 1 person (who is not the PR author) to enforce 4 eyes reviewing the changes.</p>

<p>There's a wide range of options to merge automatically once the quorum of reviewers is met or to still need a manual merge by a maintainer.</p>

<p>The permissions to review and merge can be separated which helps giving more people the right to "vote" on the merge status while keeping the possibility to restrict who can actually do the merge.</p>

CC BY-SA 3.0
2017-03-13T18:03:47.977Z
Please check the minor edit of your answer (typos stuff). If you don't like them, just rollback or re-edit, ok? Also, I hadn't thought about these PRs, so for sure very applicable I think. I'm going to mark this answer as accepted (I "learned" something from it,the things in my own answer I knew of course myself). Though I don't guarantee in the future I might change my mind (unaccept) should an even better answer get posted. About: "This allows to test on the merge from actual release (master) code with the code in the PR in an automatic way", I don't get that, should I post a new question?
Pierre.Vriens
CC BY-SA 3.0
2017-03-13T20:18:07.670Z
@pierre you're free to change your mind as often as you wish :) For the testing of proposed code, Travis CI (for exemple) can run on the result of actual master with the pull request code merged into it, so it will fail if the merge is impossible, or if the commands defined in the travisci.yml return a non zero exit code. FWIW, googling sound the best approach IMHO, the subject is large
Tensibai
CC BY-SA 3.0
2017-03-13T20:25:35.607Z
@pierre and for the edit, just one point , 4 eyes principle is to have 1 more person to review, that means 2 persons did view the change (the author didn't review it), hence the singular on variable number of person (as it could be only one, and in French maybe only one is singular :p) . I'm not as fluent in English as I'd wish to be, but I think the first point is valid (2 readers, 2 did view it making it a single review), for the second I may be biased :)
Tensibai
CC BY-SA 3.0
2017-03-13T20:41:05.723Z
aha, that's what you mean, now I get it (and took the liberty to copy/paste the extra clarification into your answer). BTW: ex**a**mple (in EN), not ex**e**mple (as in FR) ...
Pierre.Vriens
CC BY-SA 3.0
2017-03-13T20:42:41.653Z
@Pierre.Vriens blame the auto correct with dual language :)
Tensibai
CC BY-SA 3.0
2017-03-13T20:57:36.577Z
I think it's rather that the auto correct has not been tested well enough before it was released ... which is also why I have dsabled it ... I kept having all sorts of invalid auto corrections, I got tired of correcting the corrections, and hence turned it off (until a future release will have fixed the obvious errors I noticed).
Pierre.Vriens
CC BY-SA 3.0
2017-03-13T23:35:49.113Z
You are missing one of the easiest, where two operators work together, one writes up the commands, the second validate them. :)
Michaël Le Barbier
CC BY-SA 3.0
2017-03-14T06:16:25.037Z
@MichaelGrünewald yes, pair programming is another option
Tensibai
CC BY-SA 3.0
2017-03-14T08:57:04.693Z
I had system maintenance and therefore console interactions in mind, not sure if this qualifies as “pair programming”.
Michaël Le Barbier
CC BY-SA 3.0
2017-03-14T09:05:35.027Z
@MichaelGrünewald I meant he same principle, one who dictate, one who type. But I strongly feel you should not patch 'live' from console anyway :)
Tensibai
CC BY-SA 3.0
2017-03-06T10:42:08.630Z
2017-03-13T20:39:13.003Z
2017-03-13T20:39:13.003Z
Tensibai
<p>These are strategies/patterns I can think of:</p>

<h3><a href="https://en.wikipedia.org/wiki/Separation_of_duties" rel="noreferrer">Separation of Duty</a></h3>

<p>DevOps, to my view at least, does not means embodying of both dev and ops in a single person. So it is still possible to separate the duty such that the one writing the code (dev) is not the one executing it (ops).</p>

<p>For example, if an SQL statement is to be executed on the live environment, one writes the SQL and another executes it.
What this presupposed is the the one executing need to also have an understanding of the SQL and not just execute.</p>

<h3>Deploy trigger</h3>

<p>While there are merit to continuously deploy. Team in a more regulated industry can appoint another (separate) party to trigger the deploy instead of deploying automatically. Checklist, automated tests, checksums are possible checks before triggering deploy.</p>

<p>Once triggered, the automation can go ahead to execute the deployment.</p>

<h3><a href="https://en.wikipedia.org/wiki/Pair_programming" rel="noreferrer">Pair Programming</a></h3>

<p>Personally I have not cited this technique as a method to auditor to satisfy the check and balance principle. But potentially I think it can be a strategy.</p>

<h3><a href="https://en.wikipedia.org/wiki/Multi-factor_authentication" rel="noreferrer">MFA</a></h3>

<p>I might be stretching a little with this one, but it is possible that for some reason that you don't want unilateral entry into a system, someone can hold the password and another person hold the token or device for one time code. So that, 2 person must be present to assess the system.</p>

CC BY-SA 3.0
2017-03-23T18:47:36.603Z
Merci for these interesting variations! Never heard of that "Pair programming" before, that really seems like a variation of playing a piano with "4 hands"!
Pierre.Vriens
CC BY-SA 3.0
2017-03-23T19:25:24.447Z
I recently interviewed with a company that does the most intensive form of pair programming I've ever seen.  They had "pod" setups with two machines, each with one dedicated monitor and one shared monitor.  ALL development was done in pairs.  It's not for everyone, but by all reports it works well for them.
Dave Swersky
CC BY-SA 3.0
2017-03-23T17:44:40.087Z
2017-03-23T17:44:40.087Z
kenchew
<h3>Code Reviews</h3>

<p>This is about having at least 1 other person look at the code written by somebody, eg to evaluate if it meets some predefined criteria like:</p>

<ul>
<li>Coding standards (indentations, etc).</li>
<li>Inline documentation.</li>
<li>Maintainability of the code.</li>
<li>Error handling.</li>
<li>Completeness (eg <code>if/then/else</code> or <code>case/when</code> constructs cover all possible cases).</li>
</ul>

<h3>Approvals to update some target environments</h3>

<p>This is about having at least 2 confirmations from some person and/or automated system before it is allowed to update some target environment (which may be live, or may be something like some master file / baseline library). Some examples are:</p>

<ul>
<li>Only a limited set of warnings are allowed when transforming (building) source components in executable components.</li>
<li>Some set of automated tests must have completed without any probems.</li>
<li>Some human beings must have indicated their prior approval (and without that, any attempts to update the target environments will automatically fail).</li>
</ul>

CC BY-SA 3.0
2017-03-05T11:03:50.957Z
2017-03-05T11:03:50.957Z
Pierre.Vriens
<p>Michael Grünewald recently posted <a href="https://devops.stackexchange.com/posts/311/timeline#comment_394">this comment</a>:</p>

<blockquote>
  <p>A very important method you do not mention is the “four-eyes principle” which is used in the finance – either as a regulatory obligation or as a safe-guard. In the software industry it is implemented in various ways, as e.g. code reviews but also can be used to validate commands affecting live systems.</p>
</blockquote>

<p>Correct me if I'm wrong, but I was taught that the <strong>"four-eyes principle"</strong> is about something that is "approved to happen", after at least 2 human beings (and/or automated processes) gave their prior blessing. Or to use the (slightly corrected) wording about the <strong>"two-(wo)man rule"</strong> from <a href="https://en.wikipedia.org/wiki/Two-man_rule" rel="noreferrer">Wikipedia</a>:</p>

<blockquote>
  <p>The two-man rule is a control mechanism designed to achieve a high level of security for especially critical material or operations. Under this rule all access and actions requires the presence of two authorized people at all times.</p>
</blockquote>

<p>Regulatory obligations are, pretty sure, off topic here, but in the context of "safe-guard", what are the possible conceptual implementations of this four-eyes principle, which probably could apply to any platform / OS / hardware being used?</p>

<configuration><four-eyes>
What are possible implementations (or examples) of the four-eyes principle?
Pierre.Vriens
# What are possible implementations (or examples) of the four-eyes principle?

(Asked by: username_0 on 2017-03-05)

Michael Grünewald recently posted [this comment](https://devops.stackexchange.com/posts/311/timeline#comment_394):

> A very important method you do not mention is the “four-eyes principle” which is used in the finance – either as a regulatory obligation or as a safe-guard. In the software industry it is implemented in various ways, as e.g. code reviews but also can be used to validate commands affecting live systems.

Correct me if I'm wrong, but I was taught that the **"four-eyes principle"** is about something that is "approved to happen", after at least 2 human beings (and/or automated processes) gave their prior blessing. Or to use the (slightly corrected) wording about the **"two-(wo)man rule"** from [Wikipedia](https://en.wikipedia.org/wiki/Two-man_rule):

> The two-man rule is a control mechanism designed to achieve a high level of security for especially critical material or operations. Under this rule all access and actions requires the presence of two authorized people at all times.

Regulatory obligations are, pretty sure, off topic here, but in the context of "safe-guard", what are the possible conceptual implementations of this four-eyes principle, which probably could apply to any platform / OS / hardware being used?

**Tags:** configuration, four-eyes


---

## 3 answers

### Answer by username_1 on 2017-03-06. Score: 11 | Accepted answer

One of the implementation on code is the [Pull Request model](https://help.github.com/articles/about-pull-requests/) (PR) popularized by GitHub.

The main reasoning behind is that only a small set of maintainers of the product will be allowed to merge code into the release branch. Every new feature/bugfix will happen on a new branch and once done will be defined as a pull request.

This allows to test on the merge from actual release (master) code with the code in the PR in an automatic way (Travis being the most popular for public project actually) and give a first feed back on the code quality. Travis CI (for example) can run on the result of actual master with the code from the pull request merged into it, so it will fail if the merge is impossible, or if the commands defined in the travisci.yml return a non zero exit code

Once the automatic tests have passed, for the 4 eyes principle, it still requires a configurable number of persons to review and approve the change before it gets merged obviously at least 1 person (who is not the PR author) to enforce 4 eyes reviewing the changes.

There's a wide range of options to merge automatically once the quorum of reviewers is met or to still need a manual merge by a maintainer.

The permissions to review and merge can be separated which helps giving more people the right to "vote" on the merge status while keeping the possibility to restrict who can actually do the merge.

> **Comments:**
> **username_0**: Please check the minor edit of your answer (typos stuff). If you don't like them, just rollback or re-edit, ok? Also, I hadn't thought about these PRs, so for sure very applicable I think. I'm going to mark this answer as accepted (I "learned" something from it,the things in my own answer I knew of course myself). Though I don't guarantee in the future I might change my mind (unaccept) should an even better answer get posted. About: "This allows to test on the merge from actual release (master) code with the code in the PR in an automatic way", I don't get that, should I post a new question?  
> **username_1**: @pierre you're free to change your mind as often as you wish :) For the testing of proposed code, Travis CI (for exemple) can run on the result of actual master with the pull request code merged into it, so it will fail if the merge is impossible, or if the commands defined in the travisci.yml return a non zero exit code. FWIW, googling sound the best approach IMHO, the subject is large  
> **username_1**: @pierre and for the edit, just one point , 4 eyes principle is to have 1 more person to review, that means 2 persons did view the change (the author didn't review it), hence the singular on variable number of person (as it could be only one, and in French maybe only one is singular :p) . I'm not as fluent in English as I'd wish to be, but I think the first point is valid (2 readers, 2 did view it making it a single review), for the second I may be biased :)  
> **username_0**: aha, that's what you mean, now I get it (and took the liberty to copy/paste the extra clarification into your answer). BTW: ex**a**mple (in EN), not ex**e**mple (as in FR) ...  
> **username_1**: @username_0 blame the auto correct with dual language :)  
> **username_0**: I think it's rather that the auto correct has not been tested well enough before it was released ... which is also why I have dsabled it ... I kept having all sorts of invalid auto corrections, I got tired of correcting the corrections, and hence turned it off (until a future release will have fixed the obvious errors I noticed).  
> **username_2**: You are missing one of the easiest, where two operators work together, one writes up the commands, the second validate them. :)  
> **username_1**: @MichaelGrünewald yes, pair programming is another option  
> **username_2**: I had system maintenance and therefore console interactions in mind, not sure if this qualifies as “pair programming”.  
> **username_1**: @MichaelGrünewald I meant he same principle, one who dictate, one who type. But I strongly feel you should not patch 'live' from console anyway :)  

---

### Answer by username_0 on 2017-03-05. Score: 9

### Code Reviews

This is about having at least 1 other person look at the code written by somebody, eg to evaluate if it meets some predefined criteria like:

* Coding standards (indentations, etc).
* Inline documentation.
* Maintainability of the code.
* Error handling.
* Completeness (eg `if/then/else` or `case/when` constructs cover all possible cases).

### Approvals to update some target environments

This is about having at least 2 confirmations from some person and/or automated system before it is allowed to update some target environment (which may be live, or may be something like some master file / baseline library). Some examples are:

* Only a limited set of warnings are allowed when transforming (building) source components in executable components.
* Some set of automated tests must have completed without any probems.
* Some human beings must have indicated their prior approval (and without that, any attempts to update the target environments will automatically fail).


---

### Answer by username_3 on 2017-03-23. Score: 6

These are strategies/patterns I can think of:

### [Separation of Duty](https://en.wikipedia.org/wiki/Separation_of_duties)

DevOps, to my view at least, does not means embodying of both dev and ops in a single person. So it is still possible to separate the duty such that the one writing the code (dev) is not the one executing it (ops).

For example, if an SQL statement is to be executed on the live environment, one writes the SQL and another executes it.
What this presupposed is the the one executing need to also have an understanding of the SQL and not just execute.

### Deploy trigger

While there are merit to continuously deploy. Team in a more regulated industry can appoint another (separate) party to trigger the deploy instead of deploying automatically. Checklist, automated tests, checksums are possible checks before triggering deploy.

Once triggered, the automation can go ahead to execute the deployment.

### [Pair Programming](https://en.wikipedia.org/wiki/Pair_programming)

Personally I have not cited this technique as a method to auditor to satisfy the check and balance principle. But potentially I think it can be a strategy.

### [MFA](https://en.wikipedia.org/wiki/Multi-factor_authentication)

I might be stretching a little with this one, but it is possible that for some reason that you don't want unilateral entry into a system, someone can hold the password and another person hold the token or device for one time code. So that, 2 person must be present to assess the system.

> **Comments:**
> **username_0**: Merci for these interesting variations! Never heard of that "Pair programming" before, that really seems like a variation of playing a piano with "4 hands"!  
> **username_4**: I recently interviewed with a company that does the most intensive form of pair programming I've ever seen.  They had "pod" setups with two machines, each with one dedicated monitor and one shared monitor.  ALL development was done in pairs.  It's not for everyone, but by all reports it works well for them.  

---

