Blue/Green and Canary Deployments.

The integration service evolves independently of AEM components and OSGi clients. A candidate release must therefore accept requests from existing consumers throughout deployment and rollback.

A candidate may report ready while returning a changed payload, causing downstream errors or breaking session assumptions. A successful HTTP health response does not establish semantic compatibility with the consumer.

Blue/green uses separate workload labels and a controlled routing switch after candidate validation. A canary requires a routing layer that supports weighted or cohort-based traffic; a standard Service or Deployment alone is not a precise percentage-routing mechanism.

Test old and new consumers against the candidate contract, and use additive data changes before removing fields. Configure startup and readiness checks for usable service behavior, while keeping liveness focused on recoverable process failure rather than every remote dependency.

• Give stable and candidate revisions separate monitoring dimensions.
• Document routing-controller behavior for retries, sticky sessions and long-lived connections.
• Define acceptance and abort conditions before changing traffic; do not infer success from Pod counts.

For blue/green, validate the idle candidate and switch the route while retaining the previous revision for a bounded recovery window. For canary, increase exposure only after comparing meaningful request samples and error behavior.

Allow in-flight work to drain and align termination behavior with the routing layer. A route reversal cannot undo incompatible database writes, irreversible external side effects or an already-broken client contract.

Blue/green needs enough temporary capacity for both revisions but offers a clear switch point. Canary limits initial exposure, yet low traffic or biased cohorts can hide defects and prolong the decision window.

Continue with the complementary design in CI/CD Delivery to Kubernetes.

Reduced deployment risk is a target, not an asserted result. Test the abort path as carefully as the successful promotion path.

• Inject an API contract mismatch that readiness alone would miss.
• Verify observed traffic matches the intended routing policy and excludes synthetic probe traffic from comparisons.
• Revert during active requests and check draining, client retries and duplicate side effects.
• Exercise old and new service revisions against the same evolving data schema.

Traffic control contains exposure; it does not repair incompatible application changes. Choose the release strategy after defining what can safely coexist and what evidence warrants promotion.

These sources document product behavior. The design and validation approach above are engineering proposals, not claims made by the vendors.

• Kubernetes: Deployments
• Kubernetes: Ingress and controller requirements
• Kubernetes: startup, readiness and liveness probes