New CD Foundation GM fights CI/CD pipeline fragmentation

AUSTIN, Texas -- The Continuous Delivery Foundation appointed a new general manager last week, with a charter to grow the still-maturing community and distinguish it from its better-known Linux Foundation sibling, the Cloud Native Computing Foundation.

After 16 years as an engineer at Swedish telecom service provider Ericsson, and the better part of a decade as a Linux Foundation and Continuous Delivery Foundation (CDF) contributor, Fatih Degirmenci stepped up to take on the role. He replaced Tracy Miranda, head of open source at Chainguard, who served as executive director of CDF from September 2020 to January 2022. Degirmenci's official start date was June 1.

On day six of his tenure -- day four if you don't count weekends -- Degirmenci sat down during the cdCon conference to discuss what prompted him to make this move, what lies ahead for the CDF, just what sets it apart from the Cloud Native Computing Foundation (CNCF) and CI/CD pipeline fragmentation.

What prompted you to take on leading CDF?

Fatih Degirmenci

Fatih Degirmenci: I just joined as general manager of CDF, but I am not new to this community. Since 2014, I've been contributing to different Linux Foundation projects. In March 2019, CD Foundation was announced at the Linux Summit in Half Moon Bay. I was there, on site, and went to the first public meeting of the CD Foundation.

Originally, I was kind of hesitant [about becoming the general manager of CDF] because I am an engineer, and being general manager means some shift in thinking. But I've been contributing to this community for years, I believe in this community, and I can help this community by bringing its challenges and ideas back to the governing board and supporting our community investments. I come from within the community, and all of those people know me, and I know them and have been working a lot with them. I trust the community, and they trust me as well.

I felt the need to make sure that people and communities in supply chain security don't miss CI/CD, because CI/CD is the backbone for any supply chain.

I started contributing to CDF as a member of the oversight committee. Then we formed a special interest group [SIG] on interoperability, because that is something we as a community had to address -- the CI/CD ecosystem is kind of fragmented. There are lots of cool technologies, but there was little emphasis on how these different technologies could work with each other. Large organizations tend to have more than one CI/CD technology, and those organizations need to integrate those tools themselves. Communities do their best, but sometimes things don't work as expected and integration is costly. If a project makes a non-backward-compatible change, that breaks your integration. That gave us a chance to talk about how we can move from integration to interoperability, and focus on how we're passing data between different systems. So from that group starting in 2020, we developed a new SIG Events, which released a project in May called CDEvents.

Then I moved to the software supply chain area, because I have a background in security, and I felt the need to make sure that people and communities in supply chain security don't miss CI/CD, because CI/CD is the backbone for any supply chain -- it orchestrates all these different activities like code commits, security scans, deployments, rollbacks -- and the special interest group for software supply chain was formed around February this year. We had also been working on that topic already for years within the interoperability SIG, around summarization of metadata and policy-driven content delivery pipelines, but we didn't call it supply chain security explicitly because it wasn't called by that name.

One question that we've heard people ask is why there's a separate CDF -- why is it not part of CNCF?

Degirmenci: CNCF is focused on everything cloud-native, but things like continuous integration, continuous delivery and continuous deployment are so critical, and they need to be worked on in a more focused manner. If you look at the CNCF landscape, you have lots of great projects, and it may be difficult for CI/CD communities to make themselves visible there. But if we have these projects under a separate foundation, then that will help position those projects and broaden the topic of CI/CD more prominently, not drowning in a conversation that's one among many.

If you look at different industries, like web scale, healthcare, financial, telecom -- some of them have already figured cloud-native out, but some of them are still on their way to public cloud. An additional answer to why there's a separate CDF is that CDF has all these different companies, such as AWS and Netflix from web scale, Fidelity from finance, Huawei from telco, taking part in these conversations, which allows cross-pollination between these different industries.

If we go back to supply chain -- in the EU, you have the GDPR, but you may have difficulty to run the same pipelines across different regions because you are operating in these highly distributed, highly regulated environments. You have to have policies enforcing certain rules and regulations. When you are pushing a new product, you may be collecting user data, which may be against GDPR, and that would be a good input to conversations when it comes to why some industries are lagging behind and how the community could help update those things.

Again, this takes us back to how we can have a policy framework that actually gives you this much control. That's how I see this cross-pollination across industries and projects -- people coming together in this open forum where everyone can talk about their challenges and their use cases.

Is that type of policy framework being worked on in the CDF software supply chain SIG?

Degirmenci: There are different policy projects like Open Policy Agent and Kyverno, and one of the things we decided in the software supply chain SIG is not to create everything ourselves, just build things on top of what is available out there. We bumped into the CNCF [security] technical advisory group's supply chain security best practices white paper, and based on that white paper, Citi created something called the Secure Software Factory reference implementation. This reference implementation has a policy aspect, so we said, 'Let's start talking to OpenSSF contributors and see how we can collaborate there, take their reference implementation and try it.' CDF has all these CI/CD practitioners, as well as maintainers of the most widely used projects like Jenkins, Spinnaker and Tekton. And if we could look at these things from our perspective, that could make things even better, instead of us creating our own things and nobody cares.

One of the first things I need to do in my new job is to find some resources for generating a Secure Software Factory policy prototype and bring in community members that know deployment. Then they can go and poke in places, try to change things, bring in new components or bring in new pipeline stages. Michael Lieberman from [OpenSSF] joined our meeting. We are having ongoing conversations with him to help to closely collaborate. Since the SIG is very new and the SSF has been going through a name change [to FRSCA], we said, 'Let's take it slow while this project works out their logistics.' But we should soon start seeing some collaboration around this within SIG software supply chain and the SSF/FRSCA project.

Who's on board with CDEvents?

Degirmenci: We have contributors from Tekton, which is a CDF project, and Keptn. The Keptn project is under CNCF; they have an event-driven control plane for continuous delivery, but their focus is on deployment and operational aspects. CDEvents attempts to get the entire CI/CD [process], the full flow from code commit till your container image is running in production. [Mauricio Salatino, a staff engineer at VMware] brought us the first proof of concept using Tekton and Keptn, did the first prototypes around a Go SDK, and he's working to bring in Knative. And there is another stream of work going on to bring Spinnaker in [via] a Java SDK for CDEvents that will be developed and available on GitHub.

During the Google Summer of Code last year, the CDF community proposed a project to create a plugin to bring CloudEvents to Jenkins, because CDEvents is based on CloudEvents, and the CDEvents specification wasn't available yet. So Jenkins was the first community to actually go and try this events-based approach using CloudEvents, which will make it easier to make a plugin based on CDEvents. And there are contributors from other projects that are not part of the CNCF or CDF, like an Ericsson project called Eiffel.

Why is event-driven architecture a good way to approach interoperability?

Degirmenci: All the technologies used in constructing CI/CD pipelines use the concept of distributed systems -- one tool may be doing something like building artifacts, another tool may be running tests; we have a CI/CD choreographer or orchestrator sit on top of these, and the build tool and test tool don't necessarily need to know about the existence of the other. But integration forces organizations to make all those things aware of each other. With events, those technologies do what they do best without actually knowing about the existence of other systems. It's nothing new, but applying this in the CI/CD context is new. The event-driven approach helps you to plug in new tools to a pipeline without having to touch the rest of your other tools.

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.