Separation of duties is an important concept. It might seem to be incompatible with the DevOps approach, but it isn’t. In fact, in many cases, the separation of duties in the context of DevOps offers more assurance of quality, security, and auditability than traditional approaches.
Someone else would test my code, someone other than me would review my code, several others would manually approve deploying my proposed change to production, and someone else would deploy my code. This is not the right approach.
Want to introduce DevOps in your company?
Get in touch with us for expert help.
An Example of a DevOps Approach
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:
Accelerate your business workflow with automation. Implement monitoring practices and build DevOps roadmap with our DevOps managed services. Schedule a Free Evaluation.
A technology enthusiast passionate about automation, Gabriel Chutuape is a Cloud Engineer at ISmile Technologies. He’s part of the ISmile Technologies Cloud enablement team that help customers to design/solution/project engineering, integrating and implementing infrastructure technologies & services.
I’m working as Cloud DevOps Engineer. Expertise in technologies of Kubernetes, cloud services and cloud-native services, and DevOps technologies in various clouds.