4 Ways GitOps Can Make Developers’ Lives Easier

Developers are discovering the Git-centric process for application deployment makes creating code for Kubernetes environments less challenging in a number of ways. GitOps ensures developers can focus on creating applications, reducing the amount of time they have to spend configuring and managing Kubernetes clusters or dealing with other operations-related tasks.

At the heart of a deployment, we as developers must describe how we want the workload to run — yes, at some point, there’s some YAML. But by moving the state of our CI/CD pipelines forward we can improve the state of the art. The GitOps process can both lower the often dreaded learning curve and the number of operations-related challenges that developers typically face when deploying on Kubernetes.

For the developer, the lower GitOps learning curve relative to other CI/CD platforms is due to developers’ familiarity with Git. Therefore, for GitOps onboarding, the developer very likely has already completed over half of the required learning. Commit requests, stashing and pushing changes, etc. on GitHub are all part of GitOps processes. From there, the developer — as well as the entire DevOps team — is able to see faster deployments and other productivity improvements within CI/CD.

Here are four examples of why that is the case.

SEE ALSO: Understanding EOL OSS risks – and what to do

1. Developers Can Rely on Git’s Immutability

As developers, we often have questions about deployments in production, particularly when there are issues with a deployment — we might ask what version is deployed, when was it deployed, and what was in the deployment. With GitOps, we keep a record of all the elements that are deployed into the cluster using Git. This provides a set of immutable “truths” for both the development and operations teams, including audit trails, Kubernetes cluster-configuration data, commits, etc. In this way, GitOps makes version control stronger for both operations and developers. One of the consequences of this is deployments can shift left. GitOps thus puts more power into developers’ hands.

By storing configuration in git we simplify the deployment pipeline. The entire workload and any dependencies that are needed to run are stored together. When we want to do a new deployment we have a single git commit which represents all changes. This capability is especially useful as it makes it easy to move a single change through each stage of the deployment pipeline (dev/staging/prod).

One of the challenges of cloud native architectures is that microservices are often highly interdependent and can fail in complex ways. Storing everything about a deployment within git gives us everything we need to understand what is happening if there’s a problem in a deployment. Whether it’s the service definition, the configuration process, or microservices-dependency management, the developer is able to suggest changes or just check how the process looks throughout any of the stages of CI/CD.

2. Suggesting Changes is More Like Code Reviews

By extending git (and the tools around it) into operations we make it easy for DevOps teams to collaborate in a way they understand. Developers are familiar with how to handle their software code and have a range of tools for handling changes to it. In GitOps, we use the same tooling in the realm of application deployment and operations. Just like with software code, we keep it in branches and use automated guard-rails so that only specific individuals have the privileges to make changes. There are many levels to code collaboration that can be leveraged with GitOps, that make working on the declared state something developers are comfortable with.

3. GitOps will capture all information in Git

Git not only serves as the one immutable “single source of truth” but provides the audit trail. The developer may not necessarily need to rely on audit trails as much as operations and DevSecOps team members do, but they can make use of the capability to understand what changes have happened and what the motivation was behind changes to the repository that did occur. In a nutshell, for the developer — as well as for all DevOps team members — everything is just a Git log away.

Audit trails on Git are also accessible and simple for developers to look up when needed. This is because the complete history of the system is captured in the Git system of record, which developers understand.

SEE ALSO: Observability in 2022 – more open, more insight, more collaboration needed

4. More Freedom to Experiment

One of the biggest concerns that prevents development teams from moving fast is fear of what happens if things go wrong. Teams use complex systems and processes to check and double check their deployments because they can’t afford to get it wrong. But the answer isn’t to avoid error at all costs — it’s to have a quick and easy way to solve an error. GitOps allows developers to make mistakes. When there is an error it’s a simple action to roll back to the previous deployment, and thus, return back to a good state.

The fact that GitOps helps to prevent users — or attackers — from changing cluster configurations without leaving any trace is especially critical for operations and security teams. Through access control, for example, the developer should typically not have direct access to Kubernetes nodes. The effect is that the cluster configuration becomes “read only” for the developer, thus ensuring they do not have to worry about accidentally damaging the cluster. In fact, with GitOps, the user never manually accesses the Kubernetes cluster or production environment.

The Right Tool Stuff

A successful adoption of GitOps is straightforward and most teams already have the right tools and platforms they require — which GitOps supports. Besides not conflicting with CI, GitOps improves any CI system such as Jenkins, which is compatible with the approach.

The next step is to add open source Weave GitOps Core, which provides a simple on-ramp for deploying applications using GitOps. With Weave GitOps Core, we store the deployment YAML within git for the applications — any containerized application can be bootstrapped in a couple of commands. Finally, the workload can be deployed into any Kubernetes environment — anything for a local Kubernetes deployment (ie k3s), through to a managed Kubernetes cloud environment (AWS EKS; Azure AKS; Google GKE) or on-premise option such as Rancher and OpenShift. With the definition of the workload and the definition of the target cluster, Weave GitOps can then deploy and operate the workload.

GitOps helps developers become more productive by helping them deploy workloads quickly, easily, and without fear. By using GitOps, we can make deployments less complicated and involved, thus making it much easier to handle the the dreaded “wall of YAML” that often causes so much friction. At the same time, with GitOps we have a control mechanism ensuring that the operations team is not faced with increasing incidents and workload problems to manage.

The post 4 Ways GitOps Can Make Developers’ Lives Easier appeared first on JAXenter.