For efficient GitOps management in your organization you need a GitOps checklist. Here’s a handy 16 point checklist you and your team can use when getting started. Build better code faster with GitOps.
GitOps is an operational software development framework that enables organizations to manage IT infrastructure using Git and deliver software applications efficiently. It is an evolution of DevOps that combines Infrastructure-as-Code (IaC) and DevOps best practices for designing a model that can instantly reproduce the system’s cloud infrastructure and manage architecture based on the state of Git repositories. GitOps relies on Git as a source control system and acts as a control mechanism for developing, editing, updating, and deleting system architecture. Simply put, it is the practice of deploying changes from Git to production Kubernetes clusters in a reliable and automated way.
From our partners:
Organizations that have adopted GitOps experiencing accelerated delivery pipelines:
- DevOps engineers are released to build great applications
- Consistent deployments, right the first time
- Configuration drift is eliminated
- Nothing is missed and immediate deployments are possible
GitOps is different from DevOps. As your organization looks to adopt GitOps, there are many factors to be addressed along the way. It can be daunting. To make this journey easier, we’ve put together a 16-point checklist to guide you through your GitOps adoption path.
- We have adopted Kubernetes for container and infrastructure management: Adopting Kubernetes as the core technology can help the company efficiently manage workflows, accelerate application development, and get to the market faster. Kubernetes is expanding beyond simply orchestrating containers and becoming a tool for managing hardware and key middleware components for managing data.
- We have documented a clear workflow between Application Development teams and the Platform team: Conflicts over the overall lifecycle and workflow of the application within teams can be a risk to successful operations. Ensure that the Application Development and Platform teams understand which part of the software lifecycle they are responsible for. This will help both teams work together seamlessly.
- We have trained teams on the new workflows and tooling: Before you move on to new approaches like GitOps it always pays to train teams and ensure they have understood the new workflows and tools. Also, give them the time to experiment with the new tools and techniques.
- We have identified which changes can be automatically deployed to production, and which require a manual pull request: While GitOps encourages fully-automated releases, it allows for certain types of releases to be approved manually when required. In the push for greater automation, you should ensure that bad code doesn’t make it to production.
- We have declared everything in Git (this includes applications, infrastructure, networking, and configuration): Git centers around the declarative model of IaC that describes what you want to achieve instead of the steps necessary to achieve it. This bodes well with Kubernetes, which is also a declarative platform. Indeed, being declarative is the first step to GitOps adoption.
- We have decided on an initial structure for our Git repositories: Decide on a Git repository structure right at the start to prevent confusion later on. With the numerous developers using Git, and applications hosted in it, there should be ongoing clarity around how code is stored and collaborated around.
- We have selected the appropriate tooling that makes up our GitOps pipeline (Flux, Helm, Flagger, etc): Select the right tool to integrate the GitOps approach with your existing workflows. These tools can integrate with your existing GitOps pipeline. You can read more on this in this blog post.
- We have connected GitOps toolings like Flux, Helm, and Kustomize to our Git repositories: GitOps’ continuous deployment tools enable developers to run specific deployment strategies like drift detection, blue-green or canary releases, manage rollbacks, and keep track of old and new deployments. They need to be integrated with Git from where they pull new changes.
- We have configured Git webhook for build triggers: Webhook triggers allow developers to trigger a new build by sending a request to an API endpoint. GitHub, Bitbucket, GitLab, or Generic webhooks can be used to define them.
- We have completely automated GitOps Pipelines so that clusters are “always kept reconciled” with changes made in Git repositories: Automation is a key factor for implementing an effective GitOps pipeline. You can use Pull requests to modify the state of the Git repository. These changes are automatically pushed out to production clusters via the GitOps pipeline.
- We have automated a majority of testing: Even though GitOps allows you to rollback changes, incorporating automated testing makes releases more reliable.
- We have made test runs to automatically deploy changes to different environments using the new GitOps pipeline: After integrating the various GitOps tools and configuring Kubernetes, deploy test code to ensure your system is working as expected.
- We have decided where we would host our Kubernetes clusters (AWS EKS, Azure Arc, OpenShift, Bare Metal etc): You can either administer, install, and manage a Kubernetes cluster yourself or opt for a managed solution.
- We have set up policies to run security, resilience, and coding standards checks end-to-end from Git to pipeline tooling to Kubernetes clusters. (For example, leveraging a policy engine in Weave GitOps): Git allows Config as Code to meet the security, resilience, and coding standards requirements of Kubernetes clusters. All changes in Git pipelines are auditable and you can rollback a change at any time. It also ensures production matches the desired state kept in Git.
- We use dedicated secrets management service to manage sensitive data: Tightly control access to passwords, certificates, API keys, and more with dedicated secret management tools that provide a unified interface to such secrets and a detailed audit log.
- We have ensured that only Platform Engineers have direct access to production Kubernetes clusters (not developers): Setting up a Kubernetes service has become easy but keeping secure access to cluster certificates, networking setup, and access management systems are essential. These can be done by Platform Engineers creating readymade cloud resource templates for developers to consume in a self-service manner. This way, they will never need to touch the production Kubernetes cluster – which means better security and fewer errors.
As organizations quickly shift focus to DevOps automation, this checklist will help create better software development practices through GitOps. It’ll help ensure seamless operations across teams. However, do note that this checklist is not meant to be static, and you should feel free to customize it for your organization. Download as a PDF here.
For enquiries, product placements, sponsorships, and collaborations, connect with us at [email protected]. We'd love to hear from you!
Our humans need coffee too! Your support is highly appreciated, thank you!