Path · Service developers
Build a service
You own one file that describes what your service needs, and a build that turns it into a versioned service chart. Everything after that is automatic up to the dev environments.
What you own
| File (in your repository) | What it says |
|---|---|
deploy/service-chart.yaml | Your services, their kind (app keeps running, task runs and finishes), their settings and the secret names they read. Explained line by line: Reference: the service-chart.yaml contract. |
.github/workflows/ci.yaml | Calls the shared build for your stack (.NET, Python or Nx) plus the service-chart step. |
Not yours: versions, image tags, environment values and secret values. The build sets the version; product and environment owners fill in values; secrets live in Key Vault. Port, health checks and size are moving to the product repository planned.
Steps
- Write
deploy/service-chart.yaml. Declare settings with a default,"$required"(someone must fill it in) or"$url:<prefix>/<path>"(another part's address), and map variables to secret names. Start from the real example. - Add
ci.yamlcalling the golden path for your stack: .NET or Python. - Ask the product team to add your service chart to
product.yaml, add your secret names to the product's list, and set product-wide"$required"values. See Own a product. - Merge. The build pushes your images and
helm/services/<chart>:<version>. Within about 30 minutes the product pipeline makes a new product version, and the dev environments install it. - Check dev. When every part is healthy in dev/app01 the version is approved automatically. Nothing else is needed from you.
See how a build becomes a service chart
Two files go in (yours and the build's image list), one chart comes out, and the product pins it.
What can stop you
| You see | It means | Fix |
|---|---|---|
"$required" not supplied | A product or environment must set that setting | Set it at the same path in the product's configurations/helm.yaml or in cloud-config |
| A derived name with a fixed value | That variable differs per environment | Make it "$required" or "$url:"; a true constant goes in the product's configurations/helm.yaml |
| Secret not in the pool | The product does not list that secret name | Ask the product team to add it (and load the value into each environment's vault) |
| Credential-shaped value | A secret value is in a file | Move it to Key Vault; keep only its name |
Empty env: key | A YAML key with no entries | Delete the key |
<name>-secrets longer than 63 | The service name is too long | Shorten nameOverride |
| Nothing fails, but an override has no effect | It used the repository name, not the service name | Use the name from services: in your file |
| A landscape value is ignored | Your own env sets the same variable as a shared pack | Remove the variable from your file |
More traps: Deep dive: gotchas.
Read next
- Reference: the platform chart: what
appandtaskgive you - Reference: the service-chart.yaml contract and what the build makes from it
- Platform chart guide, section 11 (the service contract)
- Deep dive: values layering and the value tracer