Generative research around features and metadata important to Helm Chart users
Context
Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
You can currently publish Helm Charts to your GitLab (or any OCI registry). However, this feature of Helm v3 is still in experimental mode and may not be the standard approach moving forward. This is a problem because GitLab was intending on using the Container Registry as a Helm Chart registry.
Given this uncertainty, we need to understand how customers and really anyone using Helm is publishing and installing charts.
- Is Devon using Helm v3 and publishing charts to a container registry? Why? Why not?
- Regardless, what are they key features of a Helm chart registry? Which metadata?
- What is GitLab's go to market strategy?
Other considerations
With Jfrog deprecating ChartCenter, https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/, there may be some additional confusion among DevOps engineers.
Reach
Reach
Based on some recent customer feedback, we know believe this to have medium reach. A helm chart registry is brought up consistently by customers.
3.0 = Medium reach (~5% to ~25%).
Impact
I think we need to do this research to understand the impact. How much does this feature help people? How does it help them? We will also need to talk to our internal customers and understand the same.
1.0 = Medium impact
Confidence
100% = High confidence
Effort
The MVC will likely take a Backend Engineer 2-3 milestones and a Frontend Engineer 1 milestone. It will also take a PM and PD one milestone each for research and design.