1. Introduction
Software development has changed a lot in the last few decades. We have moved from Waterfall to Agile to DevOps to CloudNative and GitOps. The waterfall model has some advantages but the main disadvantage is that it does not fit well with projects where the requirements are changing quite frequently. Agile does not solve all the problems but the main issue it tackles is that it promotes making small changes rather than a big bang. This also helps to ship code much more quickly and the end-user can get a look-and-feel of the product much earlier – so you get the feedback much sooner.
With Agile software development, we are making more changes and more deployments compared to the Waterfall model so the deployment/release process needs to adapt to this change as well. This is where DevOps comes into play. DevOps is a process of making the software development and operations teams work together to engineer and automate the processes.
These modern applications consist of tons of microservices that need to be scaled up and down based on the load. This is where GitOps comes into play.
2. GitOps
GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD and applies them to infrastructure automation. So we can say that GitOps is a combination of Infrastructure as a Code + Merge Requests as a change engine + CI/CD automation.
2.1 Infrastructure as Code
Your environment should be stored as code in a Git repository. This could be your infrastructure, environment configurations, policies, network configurations – so basically anything about your deployment environment where you need to run your software. So instead of manually configuring each bit of your environment, it should be stored as code. This code can be declarative – which means you are declaring what state you want your environment to be in once your code is finished running. You can actually do GitOps using any version control, it doesn’t need to be Git. One of the benefits of using Git is that you will get all the tooling as a handy UI.
2.2 Merge Requests
If you are using Git as your version control the Merge Requests become your agent of change. A branch (dev, staging etc.) can represent a state of your environment. So let’s say you use master branch as your main branch which gets deployed in the production environment. When you are working on a change you can create/fork a branch from the master – do your changes in the feature branch then merge this feature branch into master. Before merging in master you can do code reviews, quality checks etc. You can also define policies based on roles – e.g. who has the right to approve a change.
2.3 CI/CD
CI stands for Continuous Integration and CD stands for Continuous Delivery. This is more of a reconciliation loop where it checks the state you are running compared to your declared final state. Now if these two states are out-of-sync your automation should reflect that. Most of the time you will be interacting with CI/CD when there is a change (MR), you probably don’t want to run CI/CD at regular intervals without any change going in as you don’t expect your current state to change by itself. These tools could be push or pull based. The idea is that your CI/CD pushes your changes in your environment. The other way is a pull-based, where you have your agent/s running which poll the git repository for any change – and if they find any change they pull that, build it and deploy it in your environment.
3. GitOps Flow
In this section, we will discuss the GitOps flow. Let’s say we want to implement a change. We will first create a feature branch from our production branch. We will then work on this branch and make all our commits. The feature branches can also be configured in the CI/CD flow – this helps us to see if our build is passing and all our tests (unit, integration, contractual etc) are passing before merging it to the production branch. Once we have completed all-out changes we create a merge request. Other people can view the merge requests and can comment on it. We can incorporate the review comments in the feature branch. Once the reviewers are happy they approve the merge request. At this time the feature branch is merged in the production branch. Once this is done the CI/CD process will build the production branch – which includes running all the tests again on the production branch. We can also include some extra checks in our master branch e.g. running a sonar build, checking for any vulnerabilities, etc.
4. GitOps vs IaC
As we have seen earlier GitOps can be assumed as Infrastructure as Code. Though they both are related there are some subtle differences between the two. In GitOps code is stored in Git repository while for IaC it may or may not be stored in any version control. It could be just living in a text file on a system.
In GitOps change is enacted via Merge Request while in IaC the code change may or may not go through a review/approval process. Since in GitOps the code is sitting in Git it is quite easy to use MR as a change trigger.
In GitOps infrastructure updates are automated while in IaC they may not. Changes in IaC can be applied in many ways – FTP/SSH to the server, command line manual runs, etc. You can say that GitOps is nothing but just doing IaC correctly.
5. GitOps Benefits
In the previous sections, we have seen what GitOps is – In this section, we will discuss some of the benefits GitOps can bring to your organization.
5.1 Documentation
First let us look at some of the benefits of storing your definitions in code. One of the biggest benefits is that you get a self-documenting environment. You don’t need to create separate documentation around executing the IaC. The other big benefit of storing IaC in version control is that you can easily see the history of the changes to your environment. Please note that GitOps doesn’t promote a non-documentation strategy but it sure reduces the extent of it. With GitOps the documentation can be done in the README which exists in the same repository where your IaC sits, so it is very easy to access and update.
5.2 Knowledge sharing
The other benefit of GitOps is that it is quite easy to share knowledge among the team members and ever across the teams. Let’s assume you have a team based in India that has built this amazing infrastructure that solves all the problems you are currently having in the UK. You can very easily see what they have done if they are using GitOps and their code is stored in version control.
5.3 Environment duplication
The other major benefit of using GitOps is that it makes it very easy to duplicate an environment. Let’s say we have a testing environment and we want to create another exact same one where we want to test out application performance. If the code is stored in version control it makes the duplication very convenient and quick.
5.4 Roll back/forward
When your IaC code is sitting in version control it is quite easy to roll back and roll forward your changes. You can even link your application version to the environment/infrastructure configuration version. Please note that it probably is not the best idea to couple these together. When your environment configuration is versioned it lowers your time to recovery and that is a huge benefit in today fast moving world.
5.5 Automation
With automation you can deploy faster and more often. Let say someone made a manual change to the environment which broke your application. When your next CI/CD runs it will make sure it will bring your environment in line with the source of truth – which is your code.
5.6 Security and Compliance
With GitOps you can define permissions and policies which will make sure the right people get access to the environments. You can easily audit this as well.
6. Technologies
In this section we will see some of the technologies involved when we use GitOps. The first one is off course git as a code repository. On top of that you need a code management tools e.g. GitLab, GitHub, Bitbucket etc. You also need a continuous integration tool – e.g. GitLab, Jenkins to automate your build, testing, quality checks, etc. You also need a continuous delivery tool – this will not only help to automate the delivery of application code but also the infrastructure code. You might also need a container registry (e.g. dockerhub) if your application needs to be containerized. You will need a configuration manager tool e.g. ansible, puppet, etc., and an infrastructure provisioning tool e.g. terraform, AWS CloudFormation, etc.
7. Conclusion
In this article, we learned about GitOps. We discussed what GitOps is and how it is related to Infrastructure as Code. Then we looked at some of the main benefits of using GitOps in an organization. In the end we looked at some of the technologies which will be involved when using GitOps. The operation engineers need to adopt a developer-centric approach in their work.
