Config management

OSGi config as code

ui.config/…/osgiconfig/
  config/                          all environments
  config.author/                   any author
  config.publish/
  config.dev/  config.stage/  config.prod/
  config.publish.prod/             most specific wins
    com.academy.phi.core.RatingClient.cfg.json

• .cfg.json format; PID = class name (factory: PID~name.cfg.json).
• Every config a human would otherwise set in configMgr lives here. The console is read-only culture on shared environments; a configMgr write on prod is an incident-in-waiting (it also shadows file config confusingly).
• Secrets are the exception: placeholders/env-var interpolation or a secrets integration — values never in git (secrets).

Dispatcher/web-server config as code

Same repo or a dedicated one, structured as baseline + per-site includes (farm design), validated in CI (dispatcher validator + httpd -t), deployed by pipeline/config-management tooling (Ansible or your platform's equivalent) with reload + health check.

Drift detection

• Periodic job diffs live OSGi config (via JMX/config export) against the artefact's expectation; differences page the platform channel.
• Dispatcher: config on disk vs git hash check in the same job.
• Any drift found is either (a) an emergency change that must be backported to git today, or (b) unauthorised and reverted. There is no (c).

Change flow

Config changes are code changes: PR → review (with the "which environments does this touch?" question answered) → pipeline → environment. Emergency console changes follow the hotfix discipline (hotfix process) including the backport step.