‎What is GitOps? – DevOps Dialogs Lightboard Series

GitOps sounds and resembles terms like 'DevOps,' so what is the difference and how are they related? GitOps is a form of DevOps and arguably a subset of DevOps. GitOps is focused on the tools and workflows that involve Git. Git is a version control utility widely used across the industry to help maintain, store and version source-code including application and infrastructure as code (IaaC) libraries. The main differentiator between GitOps and DevOps is that DevOps represents a larger umbrella of reform. DevOps provides a culture shift as well as the overall organizational changes along with specific technology changes so that teams can be more agile and deliver faster with better quality for end users. GitOps, thought of as a subset of DevOps focuses on a specific technology as the nucleus and DevOps practices exist around it, that tool being Git. On a timeline, GitOps is also a newer practice that has come around with the Kubernetes and cloud native movement for application development and delivery. How does GitOps work? In most scenarios, there are developers, someone or some team that owns an application or code base. In the Kubernetes context, the developer is pushing their code to a Git location such as GitHub or Gitlab and that code also contains files that represent the deployment of the application, which may be a combination of deployment YAML files as well as the application code itself. The application code can be built into a container image that is used by the deployment YAML. In GitOps, everything lives in git, the code is very auditable and acts as a sole source of truth for any changes, updates, or fixes. This is one of the key benefits to having teams collaborate and deploy using GitOps. The source of truth is your Git repository, which represents what is running in dev, staging or production. CI/CD does not go away, in fact it is incredibly important to GitOps, however, where CI/CD’s focus is on the whole pipeline including unit testing, integration testing, linting, and image building, GitOps really focuses on the rollouts and rollbacks of the application itself based on what is represented in repository. Therefore, CI/CD does not deploy the application as it normally would by containing credentials to environments but instead would end by creating a pull request to a GitOps enabled branch after all the pipeline steps are complete. Once the code is merged, GitOps takes over and will update or deploy the environment based on the branch that represents development, staging or production. GitOps uses two methods to deploy or rollback to an environment, Push and Pull. A push method is closer to the way CI/CD typically runs, in that code changes (merges to a GitOps enabled branch) would kick off a pipeline that would authenticate and deploy to an external environment. The pull method has become more popular and is where a GitOps agent runs within your deployment environment, watches a specific repository, and observes updates to this repo. When a change occurs, it 'pulls' those changes and applies them to the current environment. One benefit of the pull method is that credentials do not have to be known by the external CI/CD system which improves overall security posture. Check out this short high-level lightboard video helping to explain visually what GitOps is. Learn More: https://infohub.delltechnologies.com/p/dell-container-storage-modules-a-gitops-ready-platform-1/ ‎Getting started with DevOps, GitOps and an intro to OpenShift | DELL Technologies ‎developer.dell.com new hands on labs | DELL Technologies

Developer Blog

Was this post helpful?