GitOps refers to using a Git repository as the single source of truth for all the code that goes into building infrastructure and deploying applications. By using a version control system, such as Git, as the single source of truth, engineers are able to update the underlying source code for their applications in a continuous delivery format.
The version control system ensures documentation and visibility, while an audit trail enables compliance. GitOps makes it easy to revert changes and provides one place to access the most current information to help teams understand the current state from the perspective of both software development and operations teams.
GitLab is a single application for the entire DevOps lifecycle and serves as a collaboration platform that empowers stakeholders to weigh in on the code production process. Collaboration is an important aspect of the GitOps process, because teams across the entire development lifecycle - from infrastructure and development teams to security and business stakeholders - require a seamless method to collaborate to ship code quickly and efficiently.
GitOps isn't just about the code, it’s about the collaboration, and GitLab enables every team to work in a single platform.
The remaining article includes a demo on how GitLab powers GitOps through collaboration. The demo covers example epics and issues, which are linked in subsequent sections.
Since GitOps is deployment centered on version control, the first step is to define the scope of the project and identify the stakeholders. Next, team members can share any other information that might be necessary to make the project happen, such as coding, changes to infrastructure as code, what changes must be reviewed, and eventually deployed to production.
After opening an epic in the associated repository, teams can add goals and tasks in the description. An epic enables teams to track issues across different projects and milestones. An issue is the main medium for collaborating ideas and planning work in GitLab.
Example epic and issues
In this example epic, called Scale the Cloud, teams can view the process behind scaling up a Kubernetes cluster in GitLab. Because GitLab is multicloud, there are three separate issues for the demo that articulate what is required to deploy the Kubernetes cluster to each unique environment: Azure (AKS), Google (GKE), and Amazon (EKS).
At the epic level, teams can see that the issue for scaling inside the EKS cluster has already been completed. Clicking the issue reveals that a merge request was created from the tasks outlined in the issue, and that the MR is already merged.
To see what exactly has changed between the original code and current code, click inside the MR. From here, teams can see that all the tests that passed before/after merging, consult the comment history to identify changes, and make a note who approved and merged the code.
The issue for scaling to GKE is not yet completed. The merge request is still a Work in Progress (WIP), meaning nothing has been changed yet. There is a comment on the MR from Terraform, which shows that the node count needs to change from two nodes to five nodes to prepare the GKE environment for deployment. Whoever is the approver for the MR clicks Resolve the WIP Status to kick off the pipeline and can opt to delete the source branch to merge the updated node count.
In order for GitLab to be an effective collaboration tool, it also needs to be transparent which is why everyone in the organization is able to see an issue and associated MR by default. The issue and MR can be assigned to a collaborator, or the collaborator can be tagged in the comments section to have it added to their To Do list.
Navigating back to the Epic view, which is what stakeholders will often use to view project progress, teams can see that the deployment for scaling GKE to five nodes is underway.
Using GitLab for a GitOps workflow, every team member is able to work from the same system and understand the status of projects. Whether in infrastructure or in application development, all changes follow the same process of, defining the body of work, assigning it to individuals, collaborating with teammates, and deploying that code and using the Git repository as that single source of truth.