3 Steps to Developing a Successful GitOps Model
GitOps is a model that enables a streamline between development and operations flows. It brings them together through a central place for collaboration, Git, containing both configuration files and application code.
GitOps serves organizations that develop cloud-native solutions based on containerization and microservices. It enhances the developers' experience by enabling them to contribute with features without the need to know the underlying infrastructure. At the same time gives control to operations with code reviews and approvals.
GitOps improves the stability and reliability of the system and provides higher security guarantees. But the most prominent advantages coming with implementing a GitOps model in your company are probably standardization and consistency in your overall workflow.
In this article, we cover what you need to consider to develop a successful GitOps model:
Everything as Code
Start by declaring your infrastructure as code. CloudFormation, Terraform, Palumi, Crossplane are some possible declarative languages you can use to define the configuration of how you want your infrastructure to look.
Declarative code improves readability and maintenance. In addition, the practices that are part of your application code lifecycle can now be replicated to your infrastructure code as well.
In GitOps, it's common practice to use a Git repository for your IaC development. That way, you can explore the benefits such as version control, collaboration, and audits.
With technologies like Docker and Kubernetes, developing environment setup became much more manageable. You define system dependencies as code. In a dockerfile, you define your environment, versions, configurations, and dependencies, and Docker enforces those definitions on runtime.
GitOps is not limited to only infrastructure as code. Anything that can be defined as code can also use the GitOps model. This includes security, policy, compliance, all operations beyond infrastructure.
Review process
When working with application code, it's common practice to have multiple features that need to be implemented simultaneously. Therefore, leveraging a version control system is a must for software development these days, as various teams collaborate on the same codebase, and mechanisms to merge all those changes need to be in place.
If you already take advantage of the Git flow system by working with feature branches and pull requests, then you won't need to invest much in a new process for your GitOps workflow. Furthermore, as your infrastructure (and other operations) are defined as code, you'll be able to implement the same practices for code review.
A proper Git flow consists of forking or creating a new feature branch from the main branch. When someone does changes to the code, they make a pull request that should be reviewed by other team members who haven't worked on that code. They review the code, validate it and then approve it. Once approved, the code can be merged into the main branch and delivered to test or production.
This way, you can track who made which change and ensure the environment has the correct version of the code.
The same can be done with infrastructure. In an infrastructure model, typically, the main branch represents an environment, like dev, test, stage, prod, and the state running on that environment. With pull requests, developers can collaborate with operations for peer review, and security and compliance experts can also be involved in this stage to validate the environment's state properly.
Separate build and deploy process (CI and CD)
In DevOps practices, the CI/CD process is considered one entity and typically delivered in one pipeline. But with the rise of componentized applications, the pipeline between development and operations becomes more complex.
A CI (continuous integration) process is responsible for building and packaging application code into containers images.
The CD (continuous deployment) process is a crucial part of implementing GitOps. This process executes the automation to bring the end state in line with the system's desired state, described in the repository code. This is done upon a successful merge of the code in the main branch.
Ultimately, GitOps sees CI and CD as two separate processes. CI as a development process and CD as an operational process. The GitOps workflow model brings the two together.
A GitOps approach commonly used to separate these processes is to introduce another Git repository as a mediator. This repo contains information about the environment, and with every commit there, the deployment process is triggered. This way, the CI process never touches the underlying infrastructure, like the Kubernetes cluster.
Decoupling the build pipeline from the deployment pipeline is a powerful protection against misconfigurations and helps achieve higher security and compliance.
Conclusion
GitOps as an operational model uses DevOps practices known to many teams, such as IaC, version control, code review, and CI/CD pipelines.
Using GitOps, you can automate the infrastructure provisioning process and use Git as a single source of truth for your infrastructure. This is why to create a successful GitOps model, you need a declarative definition of the environment.
It would be best if you also had a pull request workflow in your team. To be able to collaborate on the infrastructure code and create operational changes, you should open a pull request. Senior DevOps engineers and security experts then review the pull request to validate the changes and merge into the main branch if everything is okay.
And at last, for a full GitOps implementation, you need to have CI/CD automation for provisioning and configuration of the underlying environment and the deployment of the defined code.
GitOps helps improve the collaboration between developers and operation teams, their productivity, and increases deployment frequency. With these improvements, teams can release faster and more secure to maintain their position in the market.
