Believe it or not, the GitOps paradigm is now going on year five since the defining piece from WeaveWorks. So, at least in theory, leveraging a declarative approach that pairs Kubernetes with GitOps pillars is not novel at this point. But the trickier question right now – and one open to no shortage of interpretation – is what you are sending to a GitOps Engine. The multiple paths of creating Kubernetes manifests and packaging (like Helm, Kustomize, JSonnett, etc) are largely leaving us to our own devices for abstraction. Is an app an app if there is no longer a templating engine?

Even with all of the abstraction today, there is not a common definition of “what” an application is. And common developer experiences force devs to jump through multiple archetypes and templates to do their jobs…and when there is any change in a GitOps Engine or CD solution, those templates need to change. This session will walk through how to use Shipa and ArgoCD to bring a common definition layer – Application-as-Code – to provide a common abstraction across all your applications. Regardless of where you are on the GitOps spectrum or your level of adoption (even if not yet on GitOps today), you will learn how you can create a common abstraction layer that supercharges your CD strategy and capabilities (and makes for a far smoother developer experience).