GitOps is gaining traction in the cloud-native environment, allowing developers to deploy software to production using their preferred tooling—a Git pull request. Infrastructure as code is the underlying principle. A change in code, for example, can affect any change in operations.
This is also where the word “GitOps” comes from Git-based operations.
Given its strong association with Kubernetes, where an operational environment can be represented declaratively in code, GitOps is commonly considered a cloud-native enabler. Kubernetes will try to match the desired state (the code) to the current state (the live instance).
A Fortune 500 company I advised recently expanded the deployment of a traditional three-tier application to a worldwide scale. Existing deployments were inefficient, prone to errors, brittle, and lacked audit controls.
Here’s how we used GitOps to tackle some major business software delivery issues, as well as the primary benefits for your team.
Enterprise software delivery challenges
Unfortunately, DevOps adoption is still in its early stages at many companies, and software is still distributed via manual or semi-automated ways. The infamous change advisory board, which is mandated (by ITIL and others) to rubber-stamp each change request, is at the heart of such deployments.
The run book, which contains instructions on how to carry out the deployment, is ubiquitous in this process. Typically, these are long, complex documents that describe a series of manual processes that must be completed. Steps are frequently skipped or completed incorrectly, leading to deployments that are not what was planned.
Because of the absence of reproducibility, operators must use SSH access as the root user to enter production systems and correct observed anomalies. Such efforts, more often than not, cause as many problems as they solve. More importantly, there is a loss of control because privileged access to production systems is required for operations workers.
A further issue occurs as a result of manual-intensive processes: the system cannot be inspected because no record of exactly what changes were made and by whom exists. The frustratingly inadequate incident response found in much enterprise software is the ultimate downside of the lack of this audit capabilities.
Frustrated customers submit service tickets, which are shuffled from one team to the next, with no one accepting responsibility for resolution and instead of blaming other employees or vendors.
How GitOps delivered
Codethink, where I work as a consultant, was charged with changing a legacy three-tier application into one with a worldwide footprint for an enterprise. The system included PowerShell scripting, Azure ARM templates, Azure DevOps Pipelines, and Git as the repository for application deployment automation. To guarantee that the deployment was fully automatable and repeatable, all of the application deployment run books were first converted into PowerShell scripts.
Standard Azure ARM templates were used to generate instances, and PowerShell Expected State Configuration (DSC) was utilized to guarantee that the end states matched the desired states, ensuring that the computing and database resources were built in a consistent manner.
A cluster of independent repositories was used to employ Git as the system of record, as follows:
- The deployment’s desired configuration was saved in the config repository.
- The configuration was checked against the enterprise IT policies in the validation repository.
- The scripts responsible for taking a given configuration (for example, from a service desk issue) and utilizing automation scripts to deploy it to a live instance were stored in the deployment repository.
Partitioning responsibilities
Partitioning responsibilities was a key design tenet of this method, which ensured that individual roles and obligations were strictly enforced. This was accomplished with Azure identity and access management, which employed finely granular access controls to specific repositories. An operator performing a deployment, for example, would not be able to access the configuration repository because it was not their responsibility.
A repository representing the deployment would be built from the configuration, validation, and deployment repositories after a successful deployment. The end-user who requested the resource would be allocated to this repository. Only the resource owner had access to the resource, ensuring strict adherence to the principle of separation of powers.
GitOps is all about Git-based operations. Here’s how this approach could be used to make an operational adjustment. Each deployed instance had its own repository, which contained all of the instance’s metadata. A change to the configuration code, which might be checked in and evaluated in a pull request, may be made to modify an instance—for example, to add a new database.
Following a successful merge, a continuous integration (CI) procedure could be used to automate the transition to the new target state. Exactly what GitOps promises!
Key benefits for your team
This somewhat unique way to utilize GitOps to solve a traditional organizational pain issue has a number of major advantages. To begin with, all modifications are totally declarative and based on code or configuration; run books are no longer required. The fact that Git is the underlying system of record means that there is a very solid and auditable record of changes.
All modifications to the target deployment are made through Git, and each change is stored in a Git changeset (underpinned by the mathematics of a Merkle Tree). The ability to automate pull request evaluations using algorithms to determine the impact of the change is another fascinating area for improvement. Consider this a computer-assisted change advisory board!
Because each stage of a CI process is done in a step, a post-mortem on a failed deployment may be performed to discover where the issue occurred and what remedial action should be taken. Imposing a flawless partition of responsibilities removes the all-too-familiar finger-pointing that occurs in a manual procedure.
The strict enforcement of separation of control by virtue of identification and access constraints utilizing Git repositories as enforcement boundaries is most crucial for the organization. Operators no longer have direct access to deployments; instead, they must gain access through an appropriate changeset in a repository.
For more info: https://www.qaaas.co.uk/testing-services/
Also Read: https://www.guru99.com/software-testing.html