Deployed versions & Rollbacks

This page provides visibility into deployment history and allows reverting Storefront and Middleware to previously deployed container images. Storefront and Middleware are deployed independently and maintain separate revision histories.

Deployment model

Deployment history represents changes applied to the runtime environment, including code deployments and configuration updates. A revision represents a specific runtime state of the application associated with a particular commit.

A new revision is created when:

• A new commit (new code in the repository) is deployed.
• A rollback is performed.
• Environment variables are modified.
• Runtime settings are changed.

A revision is always linked to exactly one commit. However, a single commit may appear in multiple revisions. This occurs when:

• A rollback redeploys a previously used image.
• Configuration changes create a new revision without changing the commit.

Current Version semantics

Current Version indicates the revision actively serving traffic. If a newer revision fails during deployment, the system continues running the last successful revision. Traffic is only switched to a revision once it becomes healthy.

Rollback model

General behavior

• Rollback performs a new deployment using a previously deployed container image.
• Rollback creates a new revision.
• Rollback changes only the container image.

Rollback does not affect:

• Environment variables
• Runtime configuration
• Deployment variables
• Autoscaling policy
• Secrets
• External systems or third-party data providers

Storefront and Middleware can be rolled back independently. Each component maintains its own revision numbering.

When rolling back, the platform redeploys the selected revision and switches traffic to it once the replicas become healthy.

Deployment lifecycle

Deployments use a Blue/Green strategy.

When a new version is deployed (including rollback):

1. A new set of replicas is created for the new revision.
2. Health checks verify that the new replicas are ready.
3. Traffic is switched to the new revision.
4. Replicas from the previous revision are terminated.

Because both revisions may exist temporarily during this process, you may briefly see replicas from two deployment versions running at the same time.

Notes

• There is no downtime during a healthy rollout.
• Each replica corresponds to a Kubernetes pod managed by the platform.
• Because new replicas are created during deployment, any in-memory state is lost.
• During rollout, the total number of replicas may temporarily increase.
• Autoscaling configuration itself is not modified, but the observed replica count may briefly exceed the steady-state value during replacement.

When to use rollback

Use rollback when:

• A newly deployed version introduces a regression.
• The application becomes unstable after a code release.
• Immediate restoration of a previously stable image is required.

When rollback will not help

Rollback will not resolve issues caused by:

• Incorrect environment variables.
• Misconfigured runtime settings.
• Infrastructure-level problems.
• Changes in external systems (CMS, eCommerce backend, payment providers).

In such cases, configuration or infrastructure must be corrected separately.