Spring Cloud Config label: pin a release to the configuration it was tested with

Treat configuration as a release input

A settlement service built against a 37-second retry window can start tomorrow with a changed main-branch value if it follows a moving label. Pinning a release tag or commit lets the deployment state exactly which configuration revision it used. Keep the application name and profile explicit; Config Server resolves the application, profile and label together. Config import controls where it is loaded; property precedence still decides which value wins.

Reject an absent revision

For required configuration, omit the optional prefix on configserver import so startup fails when the server cannot supply it. Validate required fields after binding. A successful HTTP response can still contain an unexpected value or stale checkout, so record the effective label and non-secret config fingerprint with the release. The backend lesson covers that failure.

Replay a release

Run the same artifact with a pinned label, record the resulting bound settings, then move the default branch and restart. The pinned deployment should preserve its contract. This is a release test plan; the sample properties are an implementation sketch and need a configured Config Server.

Implementation sketch

spring.application.name=parcel-settlement
spring.profiles.active=production
spring.cloud.config.label=release-47
spring.config.import=configserver:

Cost and verification

Pinned labels add release bookkeeping but make rollback reproducible. A Config Server request adds startup latency and a dependency whose outage policy must be deliberate.

Common Mistakes

• Do not call a mutable branch name an immutable release pin.
• Do not use optional import for configuration without which the service must not start.
• Do not log secret values while recording the effective configuration revision.

Read next

Spring Cloud Config import: decide whether missing remote settings stop startup, Spring Cloud Config Git cache: a healthy server can still return stale properties, Spring Boot configuration sources: test each deployment path, not a guessed order, Spring exercise: trace selected config and staged Boot migrations.