Integrating GitOps with DevOps: implementing the best of both

GitOps has become a buzzword. Developers love it, because it folds DevOps into Git, a frequently used and familiar tool. Using one tool to manage multiple DevOps activities sounds fantastic, and it can be helpful for many. The truth is GitOps has limits. In this article, we explore DevOps and GitOps, compare their similarities and differences, and examine how their principles can work together to support your software development goals.

What is DevOps?

DevOps has changed the way we approach and develop software. What is it? DevOps is a set of engineering philosophies, tools, and cultural practices that promote collaboration between development and operations teams. This collaboration reduces friction between groups and accelerates the software development lifecycle, enabling faster software delivery with quicker feedback. DevOps breaks down the silos often found in traditional software development teams.

Organizations often merge development and operations teams into a single unit, working together across the development process. This unit usually encompasses everyone involved in the development lifecycle, including quality assurance specialists and security analysts. Everyone works together to achieve a DevOps culture. They implement practices and use tools that promote continuous integration and continuous delivery (CI/CD) throughout the application life cycle.

These tools and techniques automate processes like building, testing, and deploying the application. Infrastructure as Code is another element, which we will discuss later on in this article.

What is GitOps?

GitOps borrows some ideas from DevOps and combines Git (the version control system) and operations (the resource management aspect of software development). Like DevOps, GitOps uses the existing processes of infrastructure as code (IaC), version control, code reviews, and CI/CD pipelines.

In many cases, GitOps amplifies existing DevOps practices. Deploying infrastructure via code eliminates the point-and-click process teams often use to set up environments, reducing the time to market.

This method also uses merge requests to reduce the risk of deploying bad infrastructure. At least one other person reviews the changes before merging them into the main branch. Automated deployment and testing also reduce costs and application downtime, enabling faster rollbacks.

GitOps’ traditional role in DevOps

When done well, DevOps breaks down the silo mentality and brings together teams so they can effectively work toward a common goal. GitOps is a DevOps best practice that shares principles such as collaboration, continuous improvement, and automation. It is easy to integrate a GitOps workflow into actively-employed DevOps techniques.

Many DevOps teams already use Git. After all, it is the most popular version control system worldwide, and GitOps processes revolve around it. Git lets teams frequently and quickly experiment with new infrastructure and infrastructure configurations by writing declarative code and pushing it to a repo. If changes break the infrastructure or do not behave as expected, or if you are not happy with the changes, Git history enables reverting to previous infrastructure versions.

Using GitOps to manage Infrastructure as Code

Advancements in software applications have led to the automation of many software development processes. Infrastructure automation, however, has not received the same attention. For the most part, infrastructure implementation and management have remained manual processes. Automation tools like Ansible and Terraform provide a good start, but they are not end-to-end solutions.

IaC enables you to manage and provision infrastructure using declarative code instead of the traditional, time-consuming manual processes. Combined with parameterization, IaC allows you to deploy the same service multiple times to different environments with different settings.

GitOps helps by acting as a software development mechanism for managing and automating infrastructure.

GitOps limitations for cloud-native development

GitOps benefits software development teams by streamlining infrastructure deployment. Despite how appealing its benefits may be, GitOps has its limitations. There are a few cases where GitOps falls short:

• Serverless infrastructure
• Secrets management
• Automation features

Serverless infrastructure

Adopting a GitOps strategy can be expensive and time-consuming. Serverless computing becomes an attractive option for teams that do not want to manage some or all of their infrastructure.

Serverless computing offers a way to deploy and execute your software without managing the infrastructure. The cloud provider takes care of all that for you.

Delegating the task of infrastructure management to a cloud provider like AWS Lambda or Azure Functions makes GitOps obsolete. A developer provides a function — just a block of code — to the cloud provider when using any of these. The provider executes that code. The developer’s organization does not need GitOps tools or processes to provision or manage any infrastructure to run the code.

Secrets management

Applications use secrets for authentication and other sensitive details. A string for connecting to a database is one example of a secret. We must treat these secrets with the utmost care to protect our software and systems.

Although GitOps places Git at the center of infrastructure management, Git does not help manage secrets. Keeping secrets in a public Git repo makes your application vulnerable. Private repos are not much more secure. All the repo’s contributors can see the secrets, which goes against the rules of access management and role-based access control (RBAC).

We all love Git’s history tracking feature — it is one of the main reasons we use Git. However, think about what history tracking means for your secrets. You might decide at some point to remove the secrets from the repo, but they will be available on Git history forever. As the number of repos grows, each repo will have to manage its own secrets. It is challenging for the teams managing them.

Automation limitations

The Git feature of merge and pull requests helps ensure that we do not merge and deploy bad code. However, this is a manual process requiring human intervention. It does not fit well with the idea of automation — a key GitOps principle.

YAML files drive IaC deployments. A GitOps approach stores these files in a Git repository and creates a merge request when YAML files change. When the process reviews the files and merges them to the main branch, it triggers a deployment pipeline.

This approach becomes more problematic as the number of deployment environments increases. Each environment requires a separate repository, so managing merge requests becomes more and more laborious.

Conclusion

GitOps complements an already existing DevOps strategy. Experimentation becomes much easier using a version control system like Git to automate infrastructure deployment because you can revert to a working state. Integrating GitOps into DevOps is easy since they use a similar toolset. Remember, though, GitOps, just like any other process, is not perfect and has its own pitfalls.

DevOps and GitOps are not cohesive, and should not be tightly coupled. The fact that they have shared principles means they can integrate well together, but they do not necessitate one another. Teams with DevOps cultures don’t need to use GitOps — and teams without DevOps cultures still can!

Implementing a DevOps and GitOps strategy is a journey, and CircleCI can help you and your team reach your goal faster. Explore the many DevOps tools CircleCI offers to support your DevOps and GitOps efforts.