{"id":5194,"date":"2021-11-19T12:31:18","date_gmt":"2021-11-19T12:31:18","guid":{"rendered":"https:\/\/redmonk.com\/jgovernor\/?p=5194"},"modified":"2021-11-19T16:54:50","modified_gmt":"2021-11-19T16:54:50","slug":"notes-on-gitops-potential-role-in-compliance","status":"publish","type":"post","link":"https:\/\/redmonk.com\/jgovernor\/notes-on-gitops-potential-role-in-compliance\/","title":{"rendered":"Notes on GitOps potential role in compliance"},"content":{"rendered":"

\"Macro<\/a><\/p>\n

The opportunity to use Git-based workflows for compliance purposes is currently underappreciated, but there is a growing understanding in the industry that it\u2019s a significant opportunity. One of the biggest challenges in any compliance project is understanding who did what, and when. With a GitOps-based approach you naturally track system changes, but also know who made them.<\/p>\n

A lot of the work in compliance – the job to be done – is being able to track changes to records or infrastructure. If you are providing information to auditors, or just trying to meet internally defined standards, historically you’re often running around after the fact with a spreadsheet trying to build a record or audit trail. Having a system of record in place can alleviate this overhead, and leave you doing productive work. Using GitHub or GitLab means identity and access management are effectively baked into how you work. With pull requests or merge requests, permissions are baked in. Who signed off on a change and when? That\u2019s baked into Git-based workflows.<\/p>\n

In systems today you often have people randomly making infrastructure changes, SSHing into servers, VMs or containers without controls in place. That\u2019s potentially a big problem in a regulated environment. GitOps can potentially be used to enforce guardrails. Meanwhile, the vast majority of system downtime is because of configuration changes. Yet we do a frankly horrific job of tracking these changes in IT.<\/p>\n

One of the current buzzwords making the rounds is the \u201csoftware supply chain.\u201d It’s perhaps worth thinking about actual supply chain software and the way that we’ve delivered on that. Before enterprise resource planning (ERP) systems became commonplace, data was all over the place: in spreadsheets, paper-based systems, and in separate warehousing, manufacturing, logistics, and financial systems. ERP was a packaging exercise intended to allow organizations to track everything that happened in a supply chain, with a system of record, a single source of the truth at its heart.<\/p>\n

Git is beginning to play a similar role in software. From planning or designing a system or application changes, through to the new code, and configurations. Our source code management system has become a key source of the truth, and can reveal a host of useful metrics about team and individual performance. That same metadata could be applied to compliance reporting.<\/p>\n

One of the things that helped drive and accelerate the ERP wave as it was embraced by enterprises around the world was business process re-engineering (BPR). The two went hand-in-hand: BPR and ERP software, provided by a consulting company and a software company respectively. Today, we’re really looking to package the best practices in modern software development, and the kind of approaches and opinionated methodologies that the most effective companies use. Git is a common denominator in pretty much all elite performing software development organizations.<\/p>\n

Talking of elite performers, Dr. Nicole Forsgren has helped the industry understand some of the practices common to elite and high performing software organisations through her DevOps Research Assessment Work (DORA) and book Accelerate<\/a> (with contributions from Jez Humble and Gene Kim). Nicole is now leading research into individual and organisational performance at GitHub now.<\/p>\n

We\u2019re frankly still trying to work out the best methodology that will help organisations modernise traditional IT processes, the equivalent of a BPR, though – to make the shift from Waterfall to Agile, DevOps and production excellence. There have been some successes: Continuous Delivery, Agile, Test Driven Development (TDD), etc. But organisations are still struggling to modernise at scale. Pivotal did a great job of packaging an opinionated methodology, the Pivotal Way, with opinionated software (Cloud Foundry), in some Fortune 500 organisations (AllState, Comcast, Staples, etc.) allowing some repeatability, but it never became industry redefining. With the rise of Kubernetes it became clear we\u2019d be looking at a different software stack, based on the Kubernetes.<\/p>\n

But Git is helping us move forward as an industry, as a common underlying platform, not just in the Kubernetes world, but in pretty much every community and platform in software.<\/p>\n

If we think of Martin Fowler\u2019s precepts for Continuous Integration<\/a>, some of the directives are increasingly commonplace:<\/p>\n