10 IT support · Application deployment · POSIX shell

Endpoint application deployment and rollback

A disposable endpoint accepts a release that passes package checks but fails its health test, returns to the previous version, and then installs a corrected release.

Issue: A release passes its package checks but the application is unhealthy after activation. Can the endpoint restore the last healthy version without changing the named configuration and user-state files?
Decisive evidence: Release 2.0.0 passed its hash and version checks, failed post-activation health, and restored healthy 1.0.0.E02
Result: A successful package transfer is not a successful deployment. The active version, application health, rollback result, and user-state boundary all need separate checks.
Boundary: This local macOS lab uses one synthetic application and tar packages.Full limit

Completion: Complete within stated scope
Execution: Local disposable-endpoint run
Review: Scripted assertions and artifact review
Evidence: Selected evidence on this page

macOS ARM64
POSIX shell
Versioned tar packages
Disposable endpoint root

The support question

A release passes its package checks but the application is unhealthy after activation. Can the endpoint restore the last healthy version without changing the named configuration and user-state files?

Project record: Versioned releases, the deployment wrapper, an inserted failure, rollback, new-process retests, and the public evidence package.

Interactive view

Follow the release before and after activation.

Package validation, application health, the active version, and preserved data are separate checks. Choose a state to see where the release stops.

Choose a viewBaselineFailed releaseRollback checkCorrected retest

Healthy 1.0.0 is active before a new release is introduced.

01
PackageHash and version
02
ActivationCurrent release link
03
Health checkConfiguration contract
04
Active version1.0.0 or 2.0.1
05
Named dataConfig and user state

Deployment sequence

Verify the package, activate it, test health, and prove the rollback.

01
Create a healthy 1.0.0 baseline and record the active version, health output, configuration hash, and synthetic user-state hash.
02
Activate 2.0.0 after its SHA-256 and declared version match, then let its deliberately incompatible health check fail.
03
Restore the previous release pointer and run a separate health check against 1.0.0.
04
Deploy corrected 2.0.1, retest it in a new shell process, and repeat the deployment to confirm that an already-compliant endpoint makes no activation change.
05
Compare the two named data-file hashes after failure, correction, and rerun, then validate the public evidence manifest.

Evidence from the lab

The failed activation, restored baseline, corrected release, and data boundary.

Captured output from the retained lab run. The editorial image explains the sequence and is not execution evidence.

Editorial illustration of a software release moving through failure, rollback, and correction — E01 · Illustration, not evidenceDeployment sequenceA visual explanation of baseline, failed activation, rollback, and corrected release. It was generated for this page and is not proof of execution.

declared_version=2.0.0
action=activate
health_error=missing_api_url
health_exit=42
rollback_action=restore
rollback_version=1.0.0
status=healthy
result=health-check-failed

E02 · Captured lab outputControlled health failureThe package hash and declared version match before 2.0.0 activates. Its health check then reports the missing key and the wrapper restores 1.0.0.

View artifact Back to C01

installed_version=1.0.0
config_key=server_url
state=available
status=healthy

E03 · Captured lab outputRollback retestA separate check reads the active link after the failure and runs the restored 1.0.0 health command.

View artifact Back to C01

Full evidence archive5 additional artifacts

declared_version=2.0.1
action=activate
status=healthy
health_exit=0
result=deployed
installed_after=2.0.1

E04 · Captured lab outputCorrected releaseRelease 2.0.1 uses the endpoint’s existing configuration contract and passes its activation health check.

View artifact Back to C02

retest_version=2.0.1
config_key=server_url
state=available
status=healthy

E05 · Captured lab outputNew-process retestA new shell process reads the active version, configuration, state file, and health result after correction.

View artifact Back to C02

installed_before=2.0.1
status=healthy
action=none
reason=already-compliant
installed_after=2.0.1

E06 · Captured lab outputAlready-compliant rerunThe wrapper checks the installed version and health before deciding that no activation change is needed.

View artifact Back to C02

managed_boundary=releases/
configuration_boundary=config/endpoint.conf
user_state_boundary=user-data/user-state.txt
configuration_result=unchanged
user_state_result=unchanged

E07 · Captured lab outputNamed data boundaryThe configuration and synthetic user-state hashes match before and after the failed release, correction, and rerun.

View artifact Back to C03

Public package
• baseline and controlled failure
• rollback and correction retests
• already-compliant rerun
• named data boundary
• environment, scope, and SHA-256 checksums

E08 · Captured lab outputPublic evidence manifestThe checksum list covers the baseline, failure, rollback, correction, new-process retest, compliant rerun, data boundary, environment, and limits.

View artifact Back to C01

Result and limits

What changed, and what this lab does not prove.

Result

Release 2.0.0 passed its package checks, failed health with a missing configuration key, and returned to healthy 1.0.0. Corrected 2.0.1 passed during deployment and in a separate process. A later rerun made no activation change. The two named data-file hashes did not change.

Limit

This local macOS lab uses one synthetic application and tar packages. It does not cover Windows installers, Intune, Configuration Manager, MDM, package signing, fleet deployment, production use, or interrupted activation. The data check covers two named files only.

Claims and evidence

What the evidence supports.

Release 2.0.0 passed its hash and version checks, failed post-activation health, and restored healthy 1.0.0.

The failed release remains staged but inactive, and the test covers one controlled incompatibility.

EvidenceE02 E03 E08

Corrected release 2.0.1 passed during deployment and in a new shell process; a later rerun reported the endpoint already compliant.

The result applies to one local synthetic application.

EvidenceE04 E05 E06 E08

The configuration and synthetic user-state hashes remained unchanged after failure, correction, and rerun.

The check covers two named files outside the managed release directory.

EvidenceE07 E08