When we look back into the history of web operations, it required a server room with people handling all the hardware. We had to plan well ahead to buy enough hardware to be able to scale applications. There were rules to access the server rooms and other security measures such as firewalls. It involved manual deployments and infra management.
Then we saw the rise of DevOps, which was a major buzzword in the industry. Now, there is a new term called GitOps, which is ruling the microservices and container-based platforms.
Before getting into what GitOps is, we know Git is a distributed version control system where developers can manage the source code of their applications. It has text files, certificate files or configuration files which can be maintained inside Git. Developers also use it for collaborating with different members in the team, and efficiently manage code. Now, looking at the Ops part, the term comes from DevOps which is used to release, deploy, operate and monitor code as a part of the operations.
The Rise Of GitOps
GitOps is the operational practice which uses Git as a single source of truth. It is to be noted that source control repository on Git becomes the source of truth and not the actual servers or the clusters etc. This is nothing but having your infrastructure as a code, which means all your infrastructure setup is inside a codebase. It also includes the automation of deployments, rollbacks and more. Git repo can be leveraged for version controlling system, peer-reviewing system, automating and deploying process for the production environment.
Using Git itself, developers are now doing continuous delivery and automated pipelines. Additionally, the webhooks from the Git can be leveraged to push these configurations into the Dev and test environments. Once you merge that particular pull request onto the main branch, the deployment to production happens.
How GitOps Is Maintained
GitOps allows automating everything using pipelines and deploying that to production once you merge the code into your production branch. It is called GitOps because all the configurations are managed in the Git repository.
Many developers deploy the infrastructure code as well as a part of their automation process by using only one repository for an application or a service and have a separate repository for each of them. Let’s say you have ten microservices that basically means you have ten GitOps repositories which will have the infrastructure code. Moreover, GitOps demand that developers have separate branches for each environment.
Let’s say you have three environments, namely dev, test and prod, there should be three branches — dev, test and prod. This is done to map each of these branches to different environments in the Kubernetes cluster. Once you push the changes on to that particular branch, there will be a relevant automated pipeline which will be set up. This means that whenever there is a change for that specific branch, the pipeline deploys to that environment. It also identifies, tests and verifies that the environment looks all right.
This way when a developer makes a change in their dev branch and once the dev branch succeeds, they will be able to merge pull requests in order to join it to the production branch. And once you click on merge, that is when it will deploy to the production environment. If you want to do a rollback, you can create another pull request to roll back to that particular previous state of the branch.
So, if a user goes and changes the code in the Git repository, it creates a container image, and that container image is pushed to the container registry which is updated into a config updater. Once you create a pull request to merge to a different branch, that is when it deploys to the concerned branch, and then it tests whether these are good.
This way every time you raise a pull request you know what you are merging and that the pull request is being reviewed by somebody based on the success criteria of that particular automated branch pipeline. This is how GitOps helps teams in solving the automation problem.
DevOps Vs GitOps: What Has Changed?
Previously, companies usually had separate operations and development teams, and unfortunately, they did not talk to each other too much. Luckily we have DevOps, which tries to address this by ensuring increased collaboration so that operations and development teams work closely together. In an ideal world, it meant that you have the same people who are both writing the applications and operating the applications. It means automating as much as possible to reduce the need for manual human input when operating apps. So, DevOps was a cultural change.
Now with GitOps, it takes it to the next level where teams have an operating model where they not only define their infrastructure as code but also makes deployments and changes to infrastructure as code, by submitting pull requests that people can review and approve collectively. With GitOps, you make it ubiquitous to have continuous integration on a continuous delivery server when developing your application. Once you submit a change, the server will pick it up, pull the changes, execute any automatic tests, execute any quality checks and then build the artifact. This artifact is then published to an artifact repository and deployed to infrastructure.
The Benefits Of GitOps For Teams
GitOps allows making any changes as easy as submitting a pull request. Software team members can catch any typos & errors, do the regular review and also allow knowledge-sharing across the company. With GitOps, developers can check the code repository, and if they want to roll back, they can revert a commit or push, overriding the ones which they committed at that moment.
GitOps is also evolving fast as software-as-a-service which companies use for deploying cloud-native applications onto Kubernetes clusters, and lots of new software are getting built out of Gitops.
For example, GitOps startups like Gitpod, have open-sourced the industry’s first solution for automated, pre-built dev environments. Through automation, GitPod eliminates the tedious hours of manual steps, saving developers dozens of hours. Unlike other solutions like GitHub’s Codespaces (currently in beta), Gitpod is open-source, can be self-hosted, and automates the spinning up of ready-to-code development environments with almost any code-hosting platform including GitLab, GitHub Enterprise, and Bitbucket. Gitpod allows developers to maintain dev environments as code, thus turning highly manual steps into a machine-executable part of the project’s source code.
