The key to faster software delivery? Observability.
Observability has become a much more difficult problem to solve with the rise of microservices. Questions that were difficult to answer about monolithic architectures can be down right impossible to answer about large microservice stacks. This is why our first pillar of GitOps 2.0 is observability.
New detailed views allow you to see everything related to a release—including Jira tickets, Git commits, pull requests, related services, and more. It's never been easier to tell what’s going on across all your applications.
All of your applications and services, now in one place.
Larger aggregate views make it easy to tell what’s going on across all your applications, so that you always know exactly what's going on. Drill down into any application with one click, see detailed views on the status, and perform actions like rollbacks.
Introducing logic to GitOps Flows
Another important area we’re supporting is building logic about how rollouts should occur and when. The guiding principle is that your infrastructure should reflect the state of Git. In practice, sometimes you need to be able to handle rollouts between many regions, or you may not yet be at a state where you’re ready to take humans out of the loop to do approvals. For this we’ve introduced different deployment steps for pipelines that can trigger Git synchronization based on pipeline logic.
This allows more advanced flows such as deploy, open PRs onto other infrastructure repos, or rollouts across different clusters and segments as well as automated testing of deployed versions with rollbacks.
The beginnings of GitOps 2.0
While this first step is a big win for teams delivering software there are a number of other challenges to solve. GitOps has proven to be a robust pattern for deploying software but there are still questions to answer. While we believe observability is one important one, there are more challenges to overcome. We don’t think we can solve them all ourselves so we’re going to be engaging the community. The goal is to work together to define those patterns that will help mainstream and standardize approaches to delivering software, whether it’s on Kubernetes or not.
The goal of GitOps 2.0 is ultimately to provide patterns and standards that improve software delivery and reliability. GitOps has evolved around a few core principles but has a number of questions that need to be addressed. Dealing with multiple environments, secrets, and of course observability are all key aspects that we hope to address.