CI/CD Delivery to Kubernetes.

A service can pass unit tests and still fail when its runtime configuration, network access or dependency contract changes. This scenario connects application verification with deployment checks without merging the service lifecycle into AEM package delivery.

Rebuilding for each environment makes it difficult to prove that the promoted artifact is the tested artifact. Mutable image tags and undocumented manual configuration changes make rollback equally ambiguous.

Use Git to identify source and reviewed manifests, Maven to produce the Java artifact, and a registry to retain the resulting image. A release record binds source commit, image digest, test evidence and environment configuration revision.

Run unit and integration tests before publishing the image, with code analysis and dependency checks as explicit pipeline gates. Pin base-image inputs, verify runtime startup and make the deploy identity distinct from the build identity.

• Keep registry publication permissions separate from deployment permissions.
• Use digest-pinned workload manifests and retain prior release references.
• Serialize or reconcile deployment operations so two pipelines cannot promote conflicting versions.

Apply the reviewed deployment configuration, observe rollout progress, then run smoke tests through the real service route. Promotion requires evidence about API behavior and dependency connectivity as well as available Pods.

Retain the previous digest and configuration revision, and define who can stop promotion. Deployment revision rollback does not restore externally changed data or separately mutated configuration, so those changes need their own recovery plan.

More gates can increase confidence but also create slow, brittle feedback if checks duplicate one another. Put fast deterministic tests early and reserve environment-dependent checks for the narrow release boundary they actually verify.

Continue with the complementary design in AEM CI/CD Engineering: From Maven Build to Release Validation.

The proposed technical outcome is a traceable, repeatable release process. Validation must demonstrate that rejected releases stay rejected and that a rollback restores compatible behavior.

• Compare promoted digests across environments and reject mutable-only references.
• Fail a smoke test and verify promotion stops while evidence remains available.
• Roll back the image and configuration together; check compatibility with the current data schema.
• Simulate a registry outage and overlapping release requests without losing the known-good revision.

The immutable artifact solves only part of reproducibility. A useful delivery record also explains what configuration ran, which checks passed and how operators can return to a known compatible state.

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

• Kubernetes: Deployments
• Kubernetes: startup, readiness and liveness probes
• Kubernetes: ConfigMaps