Server NewsHow the Kubernetes Release Team Works

How the Kubernetes Release Team Works

ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

COPENHAGEN, Denmark — As a community project, Kubernetes also has a community process for how releases are managed and delivered.

At the KubeCon and CloudNativeCon Europe 2018 event, Jaice Singer DuMars, OSS Governance Program Manager, and Caleb Miles, technical program manager at Google, outlined the core process and activities of the Kubernetes Release Special Interest Group (SIG).

“Fundamentally and philosophically, a release is representative of a critical bond between a project and its community,” DuMars said. “At the heart of that is really a covenant of trust and on the release team, or anything to do with releasing, you are actually holder of that trust.”

Given the growing importance of Kubernetes, DuMars said it wouldn’t be a good idea to put out a release that breaks production installations all over the world.

“Our SIG is committed to constantly improving the release process from all perspectives,” DuMars said.

DuMars stated there are over a thousand contributors to the Kubernetes community. He also noted releases generally come out within a week of a date that is picked three month in advance. One of the key things the SIG-Release does is after each release is a release-level retrospective to understand and continuously improve the process.

The Kubernetes Release Process

Kubernetes releases come together over a three-month period. The initial four-week phase is the feature definition and freeze phase, which is followed by the feature work phase and then finally the bug fixing and final release.

“I would say that the release process is one of the best ways to see the entire gravitas of the project,” DuMars said.

The SIG-Release team is also aiming to serve as an example to other Kubernetes SIGs, and to that end was the first to create established roles. All those roles are outlined and defined in a GitHub repo. As part of establishing roles, the SIG Release has also mandated that a release lead cannot be the lead for two releases in a row.

“We want the ability to replace the people in leadership positions, and that’s really important, because burn-out is real, and we need to guard our time carefully,” DuMars said.

Kubernetes release cycle

Sean Michael Kerner is a senior editor at ServerWatch and Follow him on Twitter @TechJournalist.

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends & analysis

Latest Posts

Related Stories