Skip to content

Application Lifecycle: Development to Deployment

The exporter lifecycle has four linked phases: image creation, Helm chart management, environment configuration, and deployment to Webex Kubed.

Complete Lifecycle

sequenceDiagram
    participant Dev as Engineer
    participant App as Exporter Repository
    participant Harness as Harness
    participant ECR as ECR Registry
    participant Chart as Kubed Chart Repository
    participant Config as WxCDI Config Repository
    participant Argo as WBX3 or Argo
    participant Keeper as InfoSec Keeper
    participant K8s as Kubernetes Cluster

    Dev->>App: Merge tested source change
    App->>Harness: Trigger image pipeline
    Harness->>ECR: Publish tagged image and digest
    Dev->>Chart: Update chart and chart version
    Chart->>ECR: Publish approved chart
    Dev->>Config: Select chart, image, and environment values
    Config->>Argo: Trigger approved deployment workflow
    Argo->>Keeper: Resolve managed secret material
    Argo->>K8s: Render and deploy Helm release
    K8s-->>Dev: Report workload and telemetry health

Phase 1: Docker Image Creation

  1. Implement and test the exporter/service change in its owning repository.
  2. Open a pull request with impact, test evidence, rollout, and rollback information.
  3. Merge after review and required checks.
  4. Harness builds, tests, scans, tags, and publishes the image.
  5. Record the image tag and immutable registry digest.

The historical tag format is:

<short-git-commit-sha>-<harness-build-number>

The source commit provides code traceability; the build number identifies the pipeline run. Confirm the pipeline still uses this convention before relying on it programmatically.

Phase 2: Helm Chart Management

  1. Create or update the chart in the Webex Kubed chart repository.
  2. Increment version in Chart.yaml for every chart change.
  3. Update appVersion where the chart uses it to describe the application release.
  4. Run helm lint and render with representative non-sensitive values.
  5. Open a pull request and obtain peer/platform review.
  6. Merge and verify the chart pipeline publishes the expected chart version.

See Helm for chart structure and validation.

Phase 3: Configuration Management

Environment values are maintained in wxcdi-kubed-configs.

  1. Select the service, environment, region, and cluster path.
  2. Update the chart version, image tag, and required non-secret values.
  3. Make the same intentional change for each affected production cluster.
  4. Open a pull request with rendered/diff evidence.
  5. Obtain peer review and follow the repository's current merge/deployment policy.

Do not copy Keeper values into Helm values. Reference the managed secret integration.

Phase 4: Kubernetes Deployment

The old guide documents a WBX3/Argo workflow triggered by a review comment in the configuration pull request. It explicitly distinguishes that review comment from a regular PR comment. Confirm the current syntax in the repository because deployment triggers and merge rules can change.

Historical command shape:

argo deploy <application-config-file> wbx3Cluster=<target-cluster>

The deployment workflow:

  1. validates the requested application and cluster;
  2. resolves the chart and image versions;
  3. retrieves approved secret material from Keeper;
  4. renders the Helm release;
  5. deploys/reconciles Kubernetes resources;
  6. reports the deployment result back to the pull request or pipeline.

Deployment Verification

Verify every affected cluster:

kubectl rollout status deployment/<deployment> -n <namespace>
kubectl get pods,services,endpoints -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Then verify the service outcome:

  • exporter/receiver health endpoint;
  • inventory target discovery or pushed-traffic ingress;
  • latest Prometheus/Mimir or Splunk data;
  • dashboard behavior;
  • affected alerts and resolved-notification path.

Rollback

Restore the previously verified chart/image/config version through the same source-controlled workflow. Record the prior digest and chart version before deployment so rollback does not depend on guesswork.

See Deployment MoP for the full procedure.