How to Unify SaaS and Private Deployments with Helm‑Based Version Management

Author Cui Liqiang, a Flow pipeline developer at CloudEffect, discusses the growing demand for private deployments of SaaS products and the difficulty of managing both SaaS and private release processes efficiently.

SaaS Service Versioning Limitations

Software delivery has two basic scenarios: large‑version releases and SaaS incremental updates. Large‑version releases (e.g., Jenkins 2.319.2) are clear, reproducible, and can be installed on any machine, while SaaS updates occur on a single running instance and prioritize rapid feature delivery over repeatable installation, leading to complex dependencies over time.

The diagram shows the different delivery rhythms of SaaS versus large‑version releases.

When a product needs both overseas and private deployments, teams face a dilemma: sacrifice efficiency for a pure versioned release, or keep the SaaS rhythm and manually reconcile private versions before each major release.

Unified Version Format

The version must be a complete system description, including all images, configurations, and any artifacts required to launch a new environment with a single command.

Each environment has a baseline version that matches its current runtime state.

Any service update in an environment generates a new version for the whole environment, even if only one service changed.

Configuration should be centralized, reducing duplication and making changes obvious, especially when creating new environments.

All environment changes—code, artifacts, or configuration—must be reflected in the version, enabling exact replication in other data centers.

Daily release activities are essentially version‑change scenarios wrapped in pipelines (e.g., building a temporary version for a service change, updating the baseline for a configuration change).

Helm‑Based Version Management and Deployment

On Kubernetes, Helm charts are the natural choice for the unified version format.

Helm organizes a set of Kubernetes resource files with variable placeholders.

It provides a variable management mechanism that extracts all version variables into a single file for easy maintenance.

A rendering engine substitutes variables at runtime and applies the manifests to the cluster.

Helm tracks deployment history, supporting update and rollback operations.

Using Helm’s templating, an environment description is split into two parts: immutable template files shared across environments, and environment‑specific variable files.

Because Helm charts are just collections of description files, they can be stored as directories in Git, providing version sequencing and easy collaboration.

Some Small Details

Tag all container images with date and commit ID to facilitate rapid issue tracing.

Before updating an environment in the CD pipeline, ensure the baseline matches the running state; otherwise abort to avoid unintentionally applying stale code.

Scaling Best Practices

The biggest advantage of this approach is that it relies on standard, flexible components, making it highly customizable. However, the flexibility also means teams need deep expertise in the underlying tools. To lower the entry barrier, the solution can be productized.

CloudEffect’s AppStack does exactly this by offering white‑screen application orchestration, version management, and enterprise‑grade templates, turning the Helm‑based workflow into an out‑of‑the‑box best‑practice platform.