A survey of 660 software development professionals finds 93% have embraced GitOps as a methodology for building and deploying software, with 68% planning to increase usage.
Conducted by Octopus Deploy, a provider of an automation platform for releasing software, the survey finds another quarter (25%) plan to retain their current usage compared to 7% that plan to reduce or stop GitOps usage.
Steve Fenton, director of developer relations for Octopus Deploy, said the survey also makes it clear that GitOps maturity levels also tend to vary considerably. For example, under one-third of organizations use GitOps across less than 20% of their production systems. The survey also finds only 35% of respondents that have adopted GitOps make use of continuous reconciliation and automatic rollback mechanisms. That suggests that many organizations might only be going so far as to house infrastructure-as-code (IaC) configurations alongside source within a centralized Git repository.
GitOps, at its core, refers to the process of automating the provisioning and management of IT infrastructure using a set of best practices that extend to include IaC tools. Ideally, a GitOps workflow should ensure a system is managed declaratively, automatically pulls the desired state declarations from the source, stores that data in a way that enforces immutability and versioning, and then provides some way to observe those interactions.
Once infrastructure is managed with code, it becomes easier to converge the management of IT operations and application deployment. Kubernetes, meanwhile, provides an ideal GitOps platform because it presents a standard set of application programming interfaces (APIs) that enable clusters to automatically pull code as required versus requiring an IT team to manually push code out to a platform.
Regardless of the level of GitOps maturity, there tends to be a high correlation between adoption of GitOps and modern IT platforms such as Kubernetes, noted Fenton. In general, many organizations are typically inclined to rethink legacy processes whenever a new platform is adopted, he added. In fact, it’s not uncommon for a team that has adopted GitOps to deploy microservices-based applications to be working along software engineering teams that are using legacy approaches to deploy more monolithic applications, said Fenton.
A GitOps workflow should ultimately make it simpler for IT operations to achieve continuous delivery of applications, a goal that has remained elusive despite the widespread deployment of continuous integration/continuous delivery (CI/CD) platforms. In fact, while CI is widely used to build applications, the percentage of organizations consistently using CD to deploy software has remained comparatively small.
It’s not clear to what degree the rise of platform engineering as a methodology for managing DevOps workflows at scale might drive increased adoption of GitOps. The one thing that is certain is that as the pace of application development continues to accelerate in the age of artificial intelligence (AI), the need to revisit software engineering workflows will become apparent. The only issue to be resolved now is determining how much to revamp existing workflows versus opting to simply start over again from scratch.
