Technology

Puppet Begins Effort to Define Continuous Delivery for the CDF

15 Nov 2019 10:00am, by

A green field

When the Continuous Delivery Foundation (CDF) launched earlier this year, part of its stated goals were to foster collaboration between various vendors and users, define and document best practices, and provide guidelines. Several months after launch, however, little progress had been made and there were questions around overlapping scope with the Cloud Native Computing Foundation (CNCF) and a limited dialog between founding projects. At the time, we wrote that “so far, the CD Foundation has yet to disclose specifications and primitives, although several sources say those will be communicated ‘in the coming weeks.'”

A couple months later, Puppet senior product manager Eric Sorenson decided to tackle the problem, starting with a survey of existing tools and methods. This effort comes in the form of a collaborative and shared Google doc that Sorenson hopes will lead to a set of general guidelines and recommendations.

“One of the things that I think that the community overall is interested in is enabling these kinds of vendor-neutral homes for the next-generation continuous delivery projects,” explained Sorenson in an interview with The New Stack. “The identification of how the different things, even just inside the CDF between Tekton, Spinnaker, and Jenkins make use of this — the terms and what their API contracts were — seems like a useful thing to do from a community standpoint.”

Sorenson writes in the paper’s introduction that the document is an effort to “survey the current landscape, distill the features of existing solutions into a set of requirements, and set the stage for a specification that meets those requirements with a minimum of complexity.” Currently, the survey covers Tekton, GitHub Actions, Codefresh and Spinnaker, with other projects, such as Puppet’s own Nebula CD tool, omitted because they are built on Tekton and would be redundant.

“There’s a lot of wheel reinvention going on and a lot of slightly adjacent terminology. Even the tools that people are using are really close to one another, but they haven’t yet converged on any kind of standard. I think there’s an opportunity to start a conversation,” said Sorenson. “I think that we can help the conversation along and provide a starting point for people working in this space to lift their heads up a little bit and realize that there’s a bigger world than just the immediate project or product that they’re working on.”

The document summarizes its efforts at surveying the existing implementations with the idea of creating a sort of universal translation tool to help consolidate work in continuous delivery.

“Since there’s a large overlap in approaches across the ecosystem but not a standard way of talking about the pieces, I’ve made a sort of ‘Rosetta stone’ to talk about the landscape,” writes Sorenson. “For each implementation, I’ll provide a brief introduction to the aims of the project, describe the terminology it uses down to the ‘step’ level, then talk about the elements of reusability this document is primarily concerned with: the ecosystem of contributed content and the contract between the pipeline framework and the step execution.”

In its current incarnation, the document stops short of making any specific recommendations. Instead, Sorenson said that he first wanted to make sure that he had the groundwork correct before moving forward. He did say, however, that he saw recommendations coming in three separate “buckets,” which might include the metadata of the steps themselves, the storage and file system layout that provides persistence between different steps in a continuous delivery process, and the method by which the input gets passed into the CD process, whether environment variables, JSON payloads, or otherwise.

The other factor in moving the document forward to the point of recommendations, said Sorenson, was the upcoming KubeCon in San Diego, which will also be home to the co-located Continuous Delivery Summit. Sorenson is co-hosting a panel on CI/CD tools and teams alongside others from CircleCI, Red Hat and LaunchDarkly, where he said he is hoping to further discuss this effort. In the meantime, comments and suggested edits can be made in the collaborative Google doc.

CircleCI, KubeCon + CloudNativeCon, Puppet and Red Hat OpenShift are sponsors of The New Stack.

Main photo by Anshu A on Unsplash.

A newsletter digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.