10 IT support · Application deployment · POSIX shell

Endpoint application deployment and rollback

A deliberately faulty release passes its package checks, fails its health test, rolls back to the last working version, and is replaced by 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.E01
Result: A package can pass its file checks and still leave the application unusable. The lab verifies the active version, application health, rollback, and two named data files separately.
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

Project scope

What was built and checked.

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 the two checked data files 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 checkRequired configuration key
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, including the failed activation, rollback retest, corrected release, separate-process retest, and data checks.

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

E01 · 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

E02 · 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

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

E03 · Captured lab outputCorrected releaseRelease 2.0.1 reads the endpoint’s existing configuration and passes the activation health check.

View artifact Back to C02

Full evidence archive4 additional artifacts

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

E04 · 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

E05 · 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

E06 · Captured lab outputConfiguration and user-state checkThe 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

E07 · 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.

EvidenceE01 E02 E07

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.

EvidenceE03 E04 E05 E07

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.

EvidenceE06 E07