DevOps Guide - Implementing four-eyes principle with process automation tooling

This article co-authored with Roel Hodzelmans

With great power comes great responsibility.

More and more organisations are moving towards a DevOps based organisational model, putting more and more responsibility into the hands of the teams delivering software. As part of that change - and the need due to the markets moving faster and faster - more and more organisations are investing into means to release more milestones into production faster. Therefore one of the main goals within these organisations is to automate, audit, secure and ensure correct repeatability of actions.

To make that more concrete in our world of software development, we're now talking about how to implement processes that ensure our software is correct, verified, and authorized to be put into production for end customer usage. Delivering software requires that both developers and operations find common ways of merging their processes to enable faster delivery and smoother change management.

Barriers to creating a harmonious flow are found in organizations that require more stringent  verification methods on their software release mechanisms. One of the more common requirements is that of the four-eyes principle, requiring extra approval controls before release.

Let's look at defining and implementing the four-eyes principle in a DevOps automation process.

If we look around the world we'll find the four-eyes principle as an integral part of many business domains. Before we look closer at implementing the solution for this principle, let's take a look at it's definition by the United Nations Industrial Development Organization.

What is the four-eyes principle?

The four-eyes principle means that a certain activity, i.e. a decision, transaction, etc., must be approved by at least two people. This controlling mechanism is used to facilitate delegation of authority and increase transparency. The processes in UNIDO's new business model are based on the four-eyes principle, which are facilitated by electronic approvals and workflows in the ERP system. This approach not only ensures the efficiency of processes by enabling fast decision-making while ensuring effective control and monitoring, but also brings about cultural change. Staff members are able to perform these processes irrespective whether they are at Headquarters or in the field. 

There are two really interesting (highlighted in bold text) fragments in this definition that we'll be applying in our implementation example:

1. "...facilitated by electronic approvals..."
2. "...workflows in the ERP system."

Both of these aspects, automated approval using a rule based system and process automation workflows, can be applied to our software DevOps delivery model. 

Implementing the principle

Our example DevOps implementation will focus on the software delivery model of a continuous integration and continuous delivery (CI/CD) mechanism. It's not important how that is exactly implemented as many organizations have many different components in use to achieve the same results, an automated delivery of software into production.

To meet the principle, we'll be looking at adding in some automated checks using a rule engine to ensure automated approval of software updates in a portion of our CI/CD pipeline. The second set of eyes are added with process automation tooling using user task tools.

This entire example is available for you online in a workshop where you can get hands-on at your own pace with freely available tooling. From installation of the tooling to developing all the components of your process, it's a step-by-step experience where you'll see how the four-eyes  principle can work for your DevOps processes when needed.

Figure 1: Process implementation from workshop.

So what's this automated process doing?

As shown in figure 1, a code job is submitted by a developer, the automated rules are applied to determine if a code review is needed by peers (+50 lines of code submitted). A review is possible and done by a senior group if needed. Diverse logging documents process flow as the job moves through the process before heading back for deployment. Ideal jobs pass all rules and tests for automated deployment.

Take a look at the workshop and implement the example on your own machine. Before you know it, you'll be the DevOps Hero in your corner of the world.