This document explains how Helm/DM can be used under different developer workflows. When we talk about _developer workflow_, we are interested in the process that Helm Chart developers undertake, moving from initially creating a chart to officially releasing a chart.
The purpose of this document is to outline the various workflows used in
our target use cases. It is broken into three major sections:
- A section on the anticipated workflow patterns for the `helm` command line tool
- A section on development workflow models
- A section providing sample workflow implementations for the workflow
models
The document is designed to address user experience, not the
implementation of the tools.
## tl;dr: The Workflows
Helm and DM expose tools for creating, managing, and deploying charts.
This document outlines those tools, and then provides several possible
workflows.
high-level workflows.
We envision four workflows, each satisfying different organizational needs.
We envision four high-level workflows, each satisfying different organizational needs.
- Helm Official: The workflow used for contributing to the official Helm charts repository.
- Public Unofficial: A public workflow used by another org
- Private: Non-public repository
- Private Development: Charts without repositories
Each of these workflows can be accommodated by the existing Helm tools and assumptions.
## Helm Workflows and User Experience
In this section we examine several workflows that we feel are central to
the experience of deploying, managing, and building applications using
Helm. Each workflow is followed by a basic model of where the processing
of commands occurs.
### User Workflow
The user workflow is the common case. This answers stories for the "tire
kicker" and "standard user" personas.
#### Simple deployment:
```
$ helm deploy helm:example.com/foo/bar
Created wonky-panda
```
- The client sends the server a request to deploy `helm:example.com/foo/bar`.
- The server assigns a random name `wonky-panda`, fetches the chart from
object storage, and goes about the deployment process.
#### Find out about params:
In this operation, helm reads a chart and returns the list of parameters
that can be supplied in a template:
```
$ helm list-params helm:example.com/foo/bar
Params:
- bgcolor: The background color for the home page (hex code or HTML colors)
- title: The title of the app
```
- The client sends the request to the API server
- The API server fetches the chart, analyzes it, and returns the list of
parameters.
#### Generate the params for me:
In this operation, helm generates a parameter values file for the user.
```
$ helm gen-params helm:example.com/foo/bar
Created: values.yaml
$ edit values.yaml
```
- The client sends the request to the server
- The server returns a stub file
- The client writes the file to disk
#### Deploy with params:
In this operation, the user deploys a chart with an associated values
Matt Butcher
10 years ago