AUSTIN, Texas -- The CDEvents project proposes a standard way to communicate between CI/CD tools through an event-driven architecture, which could potentially reduce integration toil and improve compliance automation for DevOps platform teams.
The project, rolled out last month, was the focus of sessions and discussions among attendees at cdCon this week. It's still in its raw early stages, but if it succeeds, CDEvents could do for DevOps pipelines what OpenTelemetry has done for distributed tracing: make it easy for users to swap specific tools in and out because they all share data in a compatible way.
"We want to make sure that when we use all these tools, we have a common understanding of what's going on," said Mauricio Salatino, staff engineer at VMware and an early leader of the CDEvents project within the Continuous Delivery Foundation (CDF), during a cdCon session. "We know for sure that we'll be adding more tools, and we don't know which tools we are going to add or how they were designed -- but we know that they can consume events and produce events."
CDEvents will consist of a series of extensions to the Cloud Native Computing Foundation's (CNCF's) CloudEvents specification, which defines a data format for event-driven architectures used by cloud services.
Event-driven architectures can be used to loosely couple distributed systems so that they respond to each other without deep integration. A well-known example of an event-driven architecture that already exists in the CI/CD realm is GitHub Actions, which configures workflows to run in response to events such as code commits.
GitHub, Azure and AWS already support the CloudEvents specification, but CDEvents will build connections to open source CI/CD pipeline tools such as Tekton and focus on events related to software delivery.
"CDEvents will be focused on metadata for the core events that pipelines execute," Salatino said in an interview following his presentation. "If you have 10 GitHub [Actions] events, CDEvents will build tools to focus on the one that says 'change approved,' for example."
In a separate cdCon session, CDEvents contributors also demonstrated how the specification can be used to build observability into pipelines based on Google Cloud's DevOps Research and Assessment team's four key metrics -- deployment frequency, lead time for changes, change failure rate and time to restore services. CDEvents-specific messages such as "ServiceUpgraded" and "ServiceDeployed" could be correlated to establish deployment frequency, for example.
Such messages could also help to calculate the lead time for changes via software configuration management (SCM) systems.
"In CDEvents, we have the ID of a change, [and when there is] a change merge event, ... that allows us to go back to the SCM and ask, 'Is that change included in this specific build?'" said Andrea Frittoli, CDEvents co-creator and an open source advocate at IBM, in a cdCon presentation. "Unfortunately, there is no single common interface in the different SCM systems to ask this question. But we hope that we can foster this kind of interface."
Before CDEvents is ready for real-world use, however, more work remains. CDEvents is currently focused on emitting rather than ingesting events; more contributors are needed to fully integrate Kubernetes controllers for Knative, Tekton and Crossplane with CDEvents; and Golang and Java SDKs are still in development.
Fidelity DevOps platform shows what CDEvents could be
If CDEvents maintainers have their way, CDEvents will allow other open source users to re-create the DevOps platform used by 15,000 developers at Fidelity Investments.
This platform uses an event-driven architecture to achieve continuous compliance for apps delivered to the global financial services company's highly regulated production environment. A utility developed by Fidelity internally called Fidelity Pipeline Library offers developers a set of reusable, standardized pipeline templates that contain event triggers.
Mauricio SalatinoStaff engineer, VMware; CDEvents contributor
These event triggers send security and compliance data to another internally developed Fidelity project, a queryable evidence store called Pipeline Intelligence. More event signals within the Fidelity Pipeline Library enforce real-time gates between pipeline stages that prevent noncompliant code from being released.
These systems are the culmination of an effort that began in 2019 in response to pipeline sprawl at the company that had become untenable.
"Without this, teams were creating pipelines that had little nuanced needs, and we weren't getting the benefits of reuse within [other] governance opportunities," said Jamie Plower, director of cloud platform architecture at Fidelity. "If we're going to introduce some sort of scalable compliance, standardization is really, really important."
Fidelity Pipeline Library and Pipeline Intelligence remain internal for now, but the potential opportunities to share them with the community and contribute to CDEvents weren't lost on Gerard McMahon, head of application lifecycle management tools and platforms at Fidelity and a CDF board member.
"We had an immediate need, so we've been building it ourselves to further prove the theory and actually get an example of a real working system," McMahon said in an interview. "The plan was always to look at how do we contribute that back and where can we get involved in CDEvents."
More OpenTelemetry-style projects to come?
OpenTelemetry has inspired similar open source data specification projects for CI/CD, including OpenFeature, a project recently contributed to CNCF by a consortium of vendors that includes Dynatrace, LaunchDarkly, GitLab, Split, Flagsmith and CloudBees. OpenFeature standardizes how observability tools and feature flag tools share data.
OpenTelemetry imitators probably won't stop there, one community member predicted.
"With everything where we collect telemetry data and we put it into code or people's actual implementations, Dynatrace's interest is clear -- we want to get more visibility into what's going on with less effort," said Alois Reitbauer, chief product officer and head of the open source program office at Dynatrace, in an interview prior to cdCon. "In continuous delivery, I could argue that if you look at Spinnaker, if you look at Argo, ... why do they all look different? Why isn't there a standard for blue-green deployment that tells you how to shift traffic?"
There isn't any project within the CDF that matches what Reitbauer described, but the general idea was appealing to one cdCon presenter who works with Spinnaker.
"It could mean you're able to swap out underlying implementations of back-end tools without changing [integrations] all the time," said Carlos Martini, senior cloud and Kubernetes architect at financial services company Vanguard, in an interview following his cdCon presentation. "It could make tools easier to use."
CDF general manager Fatih Degirmenci also didn't rule out the potential for data standardization for canary and blue-green deployments, but Kubernetes proponents argue that the container orchestrator already serves as an interoperable abstraction layer for such workflows.
"You can be using the same CI/CD tools to deploy everything, but you will still have to unify your infrastructure layer using Kubernetes as an abstraction," said Hong Wang, a founding member of the Argo Project and co-founder and CEO of Akuity, during a cdCon panel on the future of continuous delivery.
Other panelists said they were open to standards efforts outside Kubernetes.
"More open standards that we can all agree on and move forward on will play a critical role in the adoption of technology, ... which may or may not be Kubernetes," said Isaac Mosquera, head of go-to-market strategy for containers and serverless at AWS, during the panel presentation.
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.