by yukinon on 4/27/21, 6:54 PM with 4 comments
But from reading books like Accelerate, and the DevOps Handbook, to become a high performing organization, the organization needs to enable and empower developers to create automated pipelines to get their changes into production safely but as fast as possible. So it would fall under a "you build it, you run it, you own it" etc..
I'm struggling to understand how it is possible that in a world of SOX compliance, how it is possible to practice CD effectively? Or how to reconcile the agile iterative processes and embracing failure if you have to deal with a Change Approval Board?
Has anyone had any experience with this in their org of how to reconcile these two concepts?
by twunde on 4/27/21, 7:58 PM
Essentially, SOX requires separation of duties, it doesn't specify what that separation of duties should look like. That separation of duties control is to reduce the risk than an engineer could deploy unauthorized code. The most common answer is to require an approval prior to deployment at the code review/pull request step, and having automated test suites doing the quality checks. If you do end up having a change approval board, then you want to get most code changes authorized as standard changes. Major product or feature launches would go through the change approval board, but minor features wouldn't need to go through it.
by sethammons on 4/28/21, 3:00 PM
A single team can write and deploy their own services. We deploy multiple times per day as a team and hundreds of times per day as an organization.
The dev who wrote it is not the dev who approves it. We have automated test suites. Tests pass and someone on the team acts as quality assurance by verifying code and tests that were added. Anyone on the team can deploy at any time.
For auditing, all code and configuration changes are tracked in jira. If it changes the system, it gets a ticket. That ticket links to the pull request (and vise versa). The pull request cannot be merged until another person clicks approved. The PR branch is ran through the test suites and after merging, the main branch gets the same treatment. The artifacts for deployment are gated by passing master/main builds. If everything is green, then the CI/CD system allows us either to automatically roll out changes or gate them with another manual step of clicking a button. At the step right before something would be released, the approver (who didn’t write the code but is on the same team) comments on the ticket that it is verified and approved.
That’s pretty much it. From the trenches of a public company. And I got to be part of going through a dozen person start up to a several hundred person public company and go from everyone has root access with the same account and password to the world of access controls. A wild ride for sure :)
by ah88 on 4/28/21, 2:13 AM
by giantg2 on 4/28/21, 12:20 AM