Use cases

Where teams use Microconfig, and what it takes in files. The examples are small but real: each one is built with the current release.

Show for:

Spring Boot services across many environments

App teamDevOps

A new stand: 30 copied files → 1 file

Situation: every environment and every client stand holds its own copy of each service's application.yaml, and the copies drift apart.

your-git-repo/

components/orders/application.yaml        # shared by all environments
components/orders/application.prod.yaml   # only what differs in prod
envs/client-acme.yaml                     # a new stand: include: {env: base}

Result: plain application.yaml files Spring Boot reads as is, and a new stand overrides only what really differs. More →

Helm values for every service

DevOpsPlatform team

50 values.yaml with the same blocks → 1 shared component and short service files

Situation: probes, resources and the registry are copy-pasted into every values.yaml, and the chart's port doesn't always match the application's.

components/orders/values.helm

#include k8s-defaults              # probes, resources, registry

replicaCount: 2
image.repository: example/${this@name}
service.port: ${app::this@server.port}

Result: a complete build/orders/values.yaml for helm upgrade -f, with the port taken from the application config. More →

Company-wide defaults from a platform team

Platform team

12 pull requests per change → 1 commit

Situation: product teams copy the platform's monitoring, logging and tracing settings, so every change means a pull request to each team.

components/orders/application.yamlproduct team

#include monitoring, logging, tracing

monitoring.secure: false   # an explicit, reviewable exception

Result: the platform team edits one file, every service picks it up on the next build, and the build diff shows which ones changed. More →

Regions, tenants and other variants of prod

DevOps

2 full copies of prod → 1 profile with the differences

Situation: prod in Europe and in the USA differs only in database hosts and a few region settings, but lives in two full copies.

envs/prod-usa.yaml

include:
  env: prod      # the same services as prod
profiles:
  - prod          # application.prod.yaml applies
  - usa           # then application.usa.yaml

Result: a fix in prod reaches both regions, and the USA keeps only its own differences. More →

Reviewing config changes before a release

DevOpsApp team

Errors at startup in production → errors in CI

Situation: nobody sees the final effect of config changes, and a renamed key shows up only when a service starts in production.

build/payment-frontend/diff-application.yaml

payment-backend:
  path: /api -> /api/v2

Result: a broken reference fails the build in CI, and reviewers see what changes in the generated files. More →

Configs that are not YAML: logback.xml, nginx.conf, Dockerfile

App teamDevOps

N almost identical files → 1 template

Situation: every service has its own, almost identical nginx.conf or logback.xml, fixed in some services and not in others.

nginx.conftemplate

server {
  server_name ${this@name}.example.com;
}

Result: every service renders its own copy, for example server_name orders.example.com. More →

Starting from configs you already have

Platform teamDevOpsApp team

A big-bang migration → one block at a time, each step proven by an empty diff

Situation: there is already a repository of copy-pasted configs, and nobody wants a migration that might change something by accident.

Result: existing YAML and properties files are valid sources as they are. Move one copy-pasted block at a time to a shared component: if the result didn't change, the build writes no diff files at all. More →

Recognize your case? The quickstart takes about 2 minutes and shows the same mechanics on a real example.

Try it in 2 minutes →