CD Foundation’s New CEO Fights CI/CD Pipeline Fragmentation
AUSTIN, Texas — The Continuous Delivery Foundation named a new CEO last week, with a charter to grow the still-mature community and set it apart from its better-known Linux Foundation sibling, the Cloud Native Computing Foundation.
After 16 years as an engineer at Swedish telecommunications service provider Ericsson, and well over a decade as a Linux Foundation and Continuous Delivery Foundation (CDF) contributor, Fatih Degirmenci stepped in to take on this 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 the sixth day of his term – the fourth day if you don’t count the weekends – Degirmenci sat down at the cdCon conference to discuss what made him take this step, what lies ahead for the CDF , which distinguishes it from Cloud Native Computing Foundation (CNCF) and fragmentation of the CI/CD pipeline.
What prompted you to take over the management of CDF?
Fatih Degirmenci: I just joined as general manager of CDF, but I am not new to this community. Since 2014, I contribute to different Linux Foundation projects. In March 2019, CD Foundation was announced at the Linux Summit in Half Moon Bay. I was there, on the spot, and I went to the first public meeting of the CD Foundation.
At first I was a little hesitant [about becoming the general manager of CDF] because I’m an engineer, and being a general manager means a change of mentality. But I have been contributing to this community for years, I believe in this community and I can help this community by bringing their challenges and ideas to the board and supporting our community investments. I come from the community, and all these people know me, and I know them and I have worked with them a lot. I trust the community, and they trust me too.
Fatih DegirmenciManaging Director, CD Foundation
I started contributing to the CDF as a member of the oversight committee. Then we formed a special interest group [SIG] on interoperability, because that’s something that we as a community had to address – the CI/CD ecosystem is kind of fragmented. There are many interesting technologies, but little emphasis has been placed on how these different technologies might work with each other. Large organizations tend to have more than one CI/CD technology, and these organizations must integrate these tools themselves. Communities do their best, but sometimes things don’t work as expected and onboarding is expensive. If a project makes a change that is not backward compatible, it breaks your integration. It gave us the opportunity to talk about how we can move from integration to interoperability, and to focus on how we pass data between different systems. So from this group from 2020 we have developed a new GIS Eventswho released a project in May called CDEvents.
Then I moved into the field of software supply chain, as I have a background in security, and felt the need to ensure that the people and communities involved in supply chain security there’s no shortage of CI/CD, because CI/CD is the backbone of any supply chain – it orchestrates all these different activities like code commits, security scans, deployments, rollbacks – and The Software Supply Chain Special Interest Group was formed around February of this year. We’ve also been working on this for years in the interoperability GIS, around metadata synthesis and policy-based content delivery pipelines, but we didn’t explicitly call it blockchain security. supply because it was not called by that name.
One question we’ve heard people ask is why there’s a separate CDF – why isn’t it part of the CNCF?
Degirmenci: CNCF focuses 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 way. If you look at the CNCF landscape, you have a lot of great projects, and it can be difficult for the CI/CD communities to make themselves visible there. But if we have these projects under a separate foundation, it will help position these projects and broaden the subject of CI/CD more prominently, without drowning in one conversation among many.
If you look at different industries, like web scale, healthcare, finance, telecom, some of them have already figured out cloud native, but some of them are still on their way to public cloud. An additional answer to why there is a separate CDF is that CDF has all these different companies, like AWS and Netflix from web scale, Fidelity from finance, Huawei from telecom, participating in these conversations , allowing for cross-pollination between these different industries. .
If we go back to the supply chain – in the EU you have GDPR, but you may have difficulty managing the same pipelines in different regions because you operate in these highly distributed and highly regulated environments. You must have policies enforcing certain rules and regulations. When you come up with a new product, you may be collecting user data, which may be against GDPR, and it would be a good contribution to conversations about why certain industries are lagging and how the community might help update these things.
Again, this comes back to how we can have a policy framework that actually gives you that much control. That’s how I see this cross-pollination between industries and projects – people come together in this open forum where everyone can talk about their challenges and use cases.
Is this type of policy framework being developed in CDF’s Software Supply Chain MIS?
Degirmenci: There are different policy projects like Open Policy Agent and Kyverno, and one of the things that we decided in the GIS software supply chain is not to create everything ourselves, but just to build things in more of what is available. We came across the CNCF [security] Supply Chain Security Best Practices White Paper from the Technical Advisory Group, and based on that white paper, Citi created something called the Secure Software Factory Reference Implementation. This reference implementation has a political aspect, so we said, “Let’s start talking to OpenSSF contributors and see how we can collaborate on it, take their reference implementation and try it out.” CDF has all of 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 point of view, it could make things even better, instead of creating our own things and nobody cares.
One of the first things I need to do in my new job is to find resources to generate a Secure Software Factory policy prototype and bring in members of the community who are familiar with the deployment. Then they can go dig into places, try to change things, bring in new components, or bring in new pipeline stages. Michael Lieberman of [OpenSSF] join our meeting. We have ongoing conversations with him to help work closely together. Since the GIS is very new and the SSF has changed its name [to FRSCA], we said, ‘Let’s take it easy while this project works out its logistics.’ But we should soon start to see collaboration around this within the GIS software supply chain and the SSF/FRSCA project.
Who is on board with CDEvents?
Degirmenci: We have contributors from Tekton, which is a CDF project, and from Keptn. The Keptn project falls under the CNCF; they have an event-driven control plane for continuous delivery, but they focus on deployment and operational aspects. CDEvents tries to get the entire CI/CD [process]the complete flow from code commit until 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, made the first prototypes around a Go SDK, and he’s working to bring Knative. And there’s another workflow going on to bring Spinnaker [via] a Java SDK for CDEvents which will be developed and available on GitHub.
During Google Summer of Code last year, the CDF community proposed a project to create a plugin to bring CloudEvents to Jenkins, since CDEvents is based on CloudEvents, and the CDEvents specification was not yet available. So Jenkins was the first community to try this event-based approach using CloudEvents, which will make it easier to create a CDEvents-based plugin. And there are contributors from other projects that aren’t part of the CNCF or the CDF, like an Ericsson project called Eiffel.
Why is event-driven architecture a good way to approach interoperability?
Degirmenci: All of the technologies used in building CI/CD pipelines use the concept of distributed systems — one tool can do something like build artifacts, another tool can run tests; we have a CI/CD choreographer or orchestrator sitting on top of it, and the build tool and the test tool don’t necessarily need to know of the other’s existence. But integration requires organizations to make all of these things aware of each other. With events, these technologies do what they do best without knowing the existence of other systems. It’s not new, but applying it in the CI/CD context is new. The event-driven approach helps you connect new tools to a pipeline without having to touch the rest of your other tools.
Beth Pariseau, Senior Writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.