GitOpsHQ Docs
How-To Guides

Manage Catalog Assets

Publish reusable deployment assets with clear version discipline and safe adoption workflows.

Task Outcome

Reusable assets become a force multiplier for delivery speed without sacrificing governance, traceability, or rollback safety.

When To Use This Guide

  • Publishing new reusable chart/base/bundle assets.
  • Updating existing shared assets to a new immutable version.
  • Standardizing asset ownership and lifecycle across teams.

Prerequisites

  • Platform team ownership for publication standards is clear.
  • Naming and versioning policy is agreed.
  • Consumer teams know adoption and rollback expectations.

UI Route Map

  1. Open Registry and Catalog.
  2. Create or update catalog asset metadata/content.
  3. Validate and publish immutable version.
  4. Track adoption in workload/binding workflows.
  5. Monitor issues and coordinate controlled rollback if needed.

Step-By-Step Execution

Prepare asset content with clear ownership and compatibility notes.
Validate asset behavior in non-production consumption path.
Publish immutable version and document intended usage boundaries.
Coordinate phased adoption in workload/binding operations.
Track adoption results and collect runtime feedback.
Promote broad adoption only after stable evidence window.

Publication Strategy

  • Use immutable version tags for all published assets.
  • Avoid mutable tags in production-controlled workflows.
  • Platform team defines standards and approves publication quality.
  • Consumer teams remain owners of service-specific rollout decisions.
  • Adopt gradually, starting with low-risk tenants/environments.
  • Capture usage notes for approvers and on-call teams.
  • Define previous-known-good version before large rollout.
  • Document fallback owner and trigger conditions.

Validation Checklist

  • Asset version is immutable and properly documented.
  • Consumer guidance is clear and actionable.
  • Adoption rollout is phased and observable.
  • Fallback version and ownership are known.

Common Failure Modes

  • Publishing without compatibility notes.
  • Reusing mutable tags that hide actual runtime content.
  • Mixing experimental and production-ready assets in one channel.
  • Broad adoption before initial runtime verification.

Asset Release Note Template

Asset name:
Version:
Owner:
Compatibility notes:
Adoption plan:
Fallback version:
Support contact:

Continue With

  1. Configure Workloads And Bindings
  2. Create Release And Deploy
  3. Platform Playbook

On this page