## GitOps

GitOps requires three core components:

-   IaC: GitOps uses a Git repository as the single source of truth for infrastructure definitions. Git is an open source version control system that tracks code management changes, and a Git repository is a .git folder in a project that tracks all changes made to files in a project over time. Infrastructure as code (IaC) is the practice of keeping all infrastructure configuration stored as code. The actual desired state may or may not be not stored as code (e.g., number of replicas or pods).

-   MRs: GitOps uses merge requests (MRs) as the change mechanism for all infrastructure updates. The MR is where teams can collaborate via reviews and comments and where formal approvals take place. A merge commits to your main (or trunk) branch and serves as an audit log.

-   CI/CD: GitOps automates infrastructure updates using a Git workflow with continuous integration (CI) and continuous delivery (CI/CD). When new code is merged, the CI/CD pipeline enacts the change in the environment. Any configuration drift, such as manual changes or errors, is overwritten by GitOps automation so the environment converges on the desired state defined in Git. GitLab uses CI/CD pipelines to manage and implement GitOps automation, but other forms of automation, such as definitions operators, can be used as well.

GitOps workflow steps:

1.  Ensure you have a working Kubernetes cluster, and that the manifests are in a GitLab project.
2.  In the same project, register and install the GitLab agent.
3.  Configure the agent configuration file so that the agent monitors the project for changes to the Kubernetes manifests. Use the GitOps configuration reference for guidance.

https://docs.gitlab.com/ee/user/clusters/agent/gitops.html