GitOps adoption is accelerating but often comes with hurdles along the way. Learn how to simplify adoption by piecing together GitOps workflow components.
Join the DZone community and get the full member experience. GitOps is quickly gaining popularity as a continuous deployment solution, offering full application and infrastructure management through a Git-based workflow. But on this road to (workflow) riches, organizations quickly encounter two hurdles impeding their GitOps adoption. First, available GitOps tooling is overwhelmingly Kubernetes-centric. Aside from born-in-the-cloud companies, most organizations rely on a mix of technologies from on-prem and cloud VMs to Kubernetes. Using GitOps to define and deploy applications on Linux VMs is far different from doing so with Kubernetes, burdening developers with the complexity of managing those multiple pipelines. Second, no matter what infrastructure developers deploy applications to, GitOps lacks a centralized portal to help monitor and support those applications. For organizations facing these GitOps adoption challenges, DevOps teams must find a solution for taking GitOps beyond Kubernetes and do it while sparing developers from sprawling complexity. The following workflow enables GitOps as a developer-friendly approach for deploying applications to any infrastructure, using available open-source tools and new workflow components. The strategy lets organizations define a standard application definition, enabling GitOps tooling like ArgoCD to deploy applications to Kubernetes or Linux-based servers in the same manner. In addition to this simplicity, developers also gain an Internal Developer Platform (IDP) that simplifies post-deployment application management and support, again regardless of how applications were deployed.
