Git branch

GitOps – Developer centric practice

Finally, we have something for developers, DevOps practices are widely accepted, and it helps to bridge the gap between Developers and Operations team. But GitOps entire focus is on developers and developers only. It can be considered as a combination of Git and DevOps practices. It’s like all the code for the deployment of an application, and its underlying infrastructure is saved on Git repositories and combining with all the DevOps concepts say Infrastructure as Code (IaC), Continuous Integration (CI), Continuous Delivery/Deployment (CD), etc. GitOps is best used for Cloud Native applications; currently, its best case is to do application deployment and Kubernetes Cluster management. It considers Git as the single source of information and pushes all the data to Kubernetes Clusters, so there is no drift between the desired and current state. This approach is developer-friendly because they are already familiar with the tools to pull or push changes for application deployments and managing Kubernetes operations.

Declarative System: It’s essential to know the declarative system to understand why Kubernetes management is chosen as an example to explain GitOps. Declarative software follows the declaration of the desired state (which we want to achieve) instead of a sequence of commands. The declarative statement would be to create two machines and install the software into the required directory. Whereas Imperative Statements might look like below:

  • Create Virtual Machine.
  • Install the Linux OS.
  • Install the required dependencies.
  • Copy the code and move the code to another directory.
  • Repeat the above sequence of steps for one more server.

Working of GitOps.

We stated it’s a combination of Git and DevOps practices. Let’s try to understand the working of GitOps using an example.

Requirement: To host an application on the Kubernetes cluster running on the public cloud.

Solution

  1. Developers write the code to deploy the application on the Kubernetes clusters and save all the code in the Versional Control system like Git. It can be considered as Infrastructure as Code (Iac).
  2. Create a pipeline, where the purpose of CI would be to merge all the code to a central repository. CD would build, test, and deploy the application to the Kubernetes Clusters to achieve the desired state.

Now, if any new configuration is required, the developer pulls from the master branch, creates a feature branch, and makes all the changes there, then creates a merge request, which can be reviewed by other team members and ultimately merged with the master branch. Once a new configuration is pushed, the Kubernetes Cluster will automatically sync and reconfigure itself to reflect the new configuration.

Benefits of GitOps:

Below are the benefits of GitOps but are not limited to the following points only.

  • Increased Productivity and stability: CICD improves overall Productivity by improving the code quality, reducing errors, generating stable applications, and reducing time to market.
  • Enriched Developer Experience: Developers don’t need to understand the working of Kubernetes clusters.
  • Increases transparency and Audit: As there is only one tool where all the code resides, it is easier for all the team members to see each other’s contribution and easy for an organization to perform an audit.

Leave a Reply