Skip to main content

Multi-Environment Promotion

Use this pattern to move adapter definitions from development and UAT into staging and production without re-authoring them. A single versioned bundle is built once, hosted as an artifact, and installed into each environment through the same Helm-driven workflow. Only the environment-specific values (hostnames, ports, broker addresses, session identifiers) change per environment.

The source of truth is the bundle. Environments never diverge because there is nothing to edit in the environment: all environment-specific inputs are supplied as values at install time and substituted into the bundle.

Portal edits are environment-local and do not auto-promote

A change you make in the Portal is stored in that environment's database and stays there. It does not propagate to staging or production on its own. The bundle is the source of truth: to promote a live change, export the edited definition and feed it back into the bundle pipeline (commit, rebuild, re-host, helm upgrade), the same path every other change takes. Editing production directly in the Portal leaves the bundle behind and reintroduces the drift this workflow exists to prevent.

Conceptual flow​

Promotion flow: configurations are exported from the Portal to Git, built by CI into a versioned bundle, then installed into staging and production via Helm values.Portal / UATGit RepositoryVersioned BundleStagingProductionExportCIHelm ValuesHelm Values
StepWhat happens
AuthorConfigurations are created and validated in an authoring environment (typically UAT).
ExportThe finalized configurations are exported as a bundle artifact.
VersionThe bundle is checked in and tagged; CI produces a versioned artifact.
InstallHelm installs the bundle into each environment, with environment-specific values supplied separately.
SubstitutePlaceholders in the bundle (for example, broker addresses and ports) are replaced with the values for that environment.

Substitution model​

Stays the same across environmentsVaries per environment
Adapter logical structure (pipelines, routes, transformations)Broker bootstrap addresses
Component selections (which connector, which transformer)Listening ports
Business rules (conditions, filters, enrichments)Counterparty session identifiers
Bundle versionSecrets and credentials (supplied through the environment, not the bundle)

Installation behavior​

PropertyBehavior
Idempotent installationRunning the install again with the same bundle and values makes no changes.
Unchanged adapters are left aloneOnly the adapters that differ between the installed state and the bundle are updated.
Roll forward to a known-good versionTo undo a change, re-promote a previous known-good bundle version by installing it forward through the same workflow. The platform applies it as a new install, so the environment converges on that version.

Promote staging to production​

This walkthrough promotes a configuration already running in staging into production. It reuses the exact bundle staging validated and changes only the production values file. For the full build-and-host pipeline behind step 1, see CI/CD Integration; for the bundle format and ${VAR} substitution rules, see Custom Bundles and Extensibility.

  1. Build and host the versioned bundle. In CI, package the repository with the SDK image and upload the result under an immutable version identifier. This is the one artifact every environment points at.

    docker run --user "$(id -u):$(id -g)" \
      -v "$(pwd)":/workspace \
      <your-registry>/conncentric/sdk:<release-tag> \
      bundle

    aws s3 cp bundle.zip s3://<your-bundle-bucket>/custom-bundle-<version>.zip

  2. Set the per-environment values file. values-production.yaml carries the production endpoints and the bundle URL. Nothing about the adapter's logical structure changes between environments.

    # values-production.yaml
    installer:
      customBundleUrls:
        - "https://<your-hosting>/custom-bundle-<version>.zip"
      env:
        TARGET_HOST: "prod-gateway.internal"
        TARGET_PORT: "5100"

  3. Run the upgrade against production with that values file. The installer downloads the bundle named in installer.customBundleUrls and applies it once the new pods are healthy.

    helm upgrade conncentric oci://<your-registry>/conncentric/charts/conncentric --version <release-tag> \
      -n conncentric \
      -f values-production.yaml \
      --atomic \
      --timeout 5m

    To drive the bundle URL from CI instead of the values file, set it inline:

    helm upgrade conncentric oci://<your-registry>/conncentric/charts/conncentric --version <release-tag> \
      -n conncentric \
      -f values-production.yaml \
      --set installer.customBundleUrls[0]="https://<your-hosting>/custom-bundle-<version>.zip"

  4. Watch the installer job. It runs as a post-upgrade hook named conncentric-installer-<revision>, where <revision> is the Helm release revision. Confirm it ends with Installer finished successfully. before treating the promotion as done.

    kubectl get jobs -n conncentric
    kubectl logs -f job/conncentric-installer-<revision> -n conncentric

When to use​

ScenarioPattern
You need staging and production to stay in sync.Install the same bundle into both, with different values files.
Configuration drift between environments is a recurring problem.Remove environment editing as a workflow; require changes to go through the bundle.
You need to track which configuration version is installed where.Use the versioned bundle tag to identify the exact configuration in each environment.

See also​