Do you use git? Do you have a repo for your cicd pipelines? If the answer is yes, then congratulations! You’re already using GitOps. In this blog post, we will discuss how to get started with GitOps and why it’s important for continuous delivery success.
If you are unfamiliar with GitOps, it is the idea of using git as your operator, using source control to change the state of the world. This is done by using git to deploy and manage your cicd pipelines, much like how you would use a CI tool.
The main advantage of GitOps is that it allows you to have your cicd pipelines managed by the same group that manages your code. This makes it easier to get started with cicd, as you don’t need a separate tool like jenkins or circle ci.
Another benefit is the ability to make changes on demand and see them immediately in production without having to go through any of the traditional release processes (eg: stage -> prod). It also allows for faster feedback loops, so your team can start seeing bugs as they happen and fix them quickly before they become more serious issues.
GitOps provides a ton of benefits for any team, especially ones where there are multiple developers working across different stacks. It ensures that everything is versioned with source control along with providing the ability to rollback if needed while enforcing cicd pipelines which can all be managed by git itself. The only real drawback is learning some basic git commands and possibly getting set up on cloud infrastructure tools such as Terraform or CloudFormation . You’ll also need to think about how you want your build pipeline configured before starting out though this shouldn’t take long since most (if not all) of the work has already been done in the Gitops reference architecture.
It improves security
GitOps does require some access to AWS, but you don’t need full administrative privileges in order to use GitOps for your cicd pipelines. Since the goal of git-based operator pattern is that policies are code and can be versioned with source control, your team should already have a good handle on who has what type of access across all repositories (github/gitlab etc). It is highly recommended to use infrastructure as code tools such as CloudFormation or Terraform along side another tool like Jenkins X or Helm/Kubernetes Deployment Manager so that you only expose those services which make sense for each stack while enforcing least privilege practices everywhere else. This allows us to avoid giving someone complete admin rights over our entire environment.
Deploying to production
GitOps isn’t just for developing and testing, it’s also used in the build stage of cicd pipelines. This allows you to deploy your code directly into prod using git as an operator, while still adhering to continuous delivery best practices such as automated test suites and strong change management tools (eg: github review apps). The benefits are that everything is versioned with source control, so when someone changes a config value or adds a service dependency without noticing there won’t be any issues down the road since those changes will always exist within history. You can easily rollback by creating another branch with previous commits and deploying from that new branch if needed.
The cons? There aren’t really any drawbacks other than the fact that you will need to invest time in learning basic git commands and possibly some other tools (eg: terraform). The good news is that once it’s set up, GitOps becomes your one stop shop for managing all of your cicd pipelines.
So how do we get started with GitOps? There are a few steps which can help make starting out easier. First off, start small by just using git as an operator on branches within different stacks/environments . This allows you to see what changes take place without having any side effects across environments or affecting prod until you’re ready. After this, you should move towards branching entire repos instead of individual files along with enforcing CI best practices such as build verification testing and automated deployment. Then start running your cicd pipelines directly from source control to see how it works for your team, you can always stop using git as an operator with any branch if it’s not working out the way you expected.
What should I know?
GitOps is different than traditional CI/CD tools because instead of having a separate tool or service managing all of our builds (eg: jenkins), we use git itself to do this by using branching patterns within repos such as Gitflow . This allows us to create multi-branch releases which are more flexible and allow teams to work faster while keeping deployments consistent due to proper change management practices. It also comes with built in best practices, including least privilege for teams and limiting blast radius when things go wrong.
There’s also the GitOps reference architecture which can help you get started by having a plan of where to start, how to evolve your pipelines along with ensuring that all branches are fully automated and built within cicd pipelines. Once these practices become second nature they will allow you to iterate faster while keeping deployments consistent & secure throughout environments such as dev , staging , prod.
In conclusion, GitOps can help manage cicd pipelines both within dev and production. It also allows teams to iterate faster while still adhering to security best practices such as least privilege, immutability & no manual changes . This means that you’ll need to be committed in learning git commands along with branching patterns (such as Gitflow ) but the end result is worth it since you’ll be able to manage your pipelines entirely from git as an operator , without having any manual changes or services which need configuring. The only thing left is for you to start trying out GitOps in your own environment, why not give it a shot with cicd-pipelines ?