In this GitOps blog series, we’ve covered the difference between GitOps and DevOps, the common challenges GitOps poses, and how GitOps can be used to manage Kubernetes. Here, we’re talking implementation – how you can get GitOps up and running.
With a good understanding of what GitOps is, the benefits it can bring, and the challenges you might have to overcome, you might be wondering, what’s next? How do we get started with GitOps?
First up, you need to make sure GitOps is the right fit for your organisation. Engage with DevOps and IT teams to understand their current workflow and any pain points, and find out if they are open to a GitOps software delivery culture.
What are the core components of GitOps?
The next step is to design and implement best–practice processes for your infrastructure team to stick to and bring new solutions onboard. Let’s take a look at what best practice looks like. There are three core components that make up GitOps: IaC, pull requests (PRs), and continuous delivery (CD).
IaC refers to the practice of keeping all your infrastructure configurations stored as code. PRs are the change mechanism used for infrastructure updates in GitOps and CD refers to your pipeline, which continuously applies the state changes to your environment. If there are errors, GitOps automation can roll back the changes to the previous working version, ensuring environmental stability.
What are the minimum requirements?
Before you invest in platforms and tools to scale GitOps across your organisation, you’ll want to make sure you’re already up and running in a few key ways.
Step one: Git comfortable
For those still to get up and running with Git, you’ll need to choose a Git repository first. GitOps is platform–agnostic, so you can pick any local or cloud–based repository that includes pull requests (PRs, sometimes called merge requests or change requests). Some popular options include GitHub, GitLab, and Bitbucket. Get into the routine of working with PRs. You’ll need to start storing both your application code as well as your infrastructure code in Git.
Step two: organise your infrastructure code
Make sure your infrastructure code is declarative and mapped to your actual infrastructure in some fashion – for example, you might map each single repository to an app environment, or use branches within one repository to represent each environment. You’ll also need a separate CI process that produces built artifacts that your GitOps Operator can access. Some tools might only work with a specific repository. Be sure to consult with your teams to find out which works best for them.
Step three: choose a GitOps Operator
The third big decision you’ll need to make is selecting a GitOps Operator. This sits between Git and whichever orchestration system you use. Its job is to pick up the commit and pull in the new state declaration from Git. Again there are a number to choose from, with the most popular choices being Argo CD and Weaveworks Flux.
What does a GitOps workflow look like?
With all the tools and processes in place, your GitOps workflow should go a little something like this:
- An infrastructure engineer declares the infrastructure as code and pushes the code to a Git repository.
- Then, they’ll create a PR for the change.
- Other team members can review, inspect, approve the code, and merge the PR.
- The GitOps Operator picks up the merged changes with the new desired state.
- The GitOps Operator compares the desired state with the existing infrastructure to check they match. If they’re different, it will automatically update the infrastructure to reflect the desired state.
Bringing new processes and tools onboard isn’t easy. It requires a big commitment from your people and demands a high level of expertise. When it comes to implementation, you might want to involve external experts, like Adaptavist, while leaning on existing knowledge within your organisation. It’s also wise to consider hiring specialists to lead the process internally and invest in additional training to arm your people with the knowledge they need.
Ready to reach out?
If you’d like more information about getting started with GitOps, we’re here to help.