Segregation of Duties (SoD) in DevOps

Let’s get into an end-to-end example to see how the progression of code, from development to deployment, aligns with the goals of separation of duties in an organization using a DevOps approach. 

The developer works on the new application feature in a feature branch of the source. When it is ready, they issue a pull request, which requires one or more people to review the code and approve the merger of the new code back into the mainline. This includes the feature itself and automated tests. 

Once the code is checked in, a build is run that creates the executable modules that will be deployed to production. This is done via scripts and configuration. The build system puts the executable into an artifact repository. This delivery of the program is not done by a person, but by the build system. Individuals do not have permission to upload an artifact manually, helping to prevent tampering. 

Deployment from the environment to the environment can be triggered via a manual approval process or automatically based upon the previous step’s outcome. Either way, the deployment is also done by a script. At no time does a person manually move any artifacts or manually deploy code or configuration. 

Nothing is done manually except for approvals (and even they are automated from a workflow perspective). Scripts and configuration are responsible for all parts of the process. An “approval” is a manual step that also invokes a script. 

All scripts and configurations are peer-reviewed and go through a testing process before they are used. If there are manual testing steps, they are done by someone other than the person who wrote the code. 

So, how can a developer deploy their code to production? The answer is – they can’t. A script does, and the script’s integrity is reviewed by an independent person or a group of people. 

Here is the process of Segregation of Duties(SoD), as you can see below: