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.

Deployment lifecycle

Deployments use a rolling replacement strategy. During deployment (including rollback):

1. New replicas are created.
2. Health checks verify readiness.
3. Traffic is gradually shifted to the new replicas.
4. Old replicas are removed.

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.