4.7 KiB
Data-aware deployment
remote backend deploy --artifact DIRECTORY validates and uploads exactly the CI JAR and manifest through one SSH connection. The target layout is the configured Werkjournal Hostsharing installation: ~/opt/werkjournal, ~/doms/werkjournal.javagil.de/htdocs-ssl, systemd user service werkjournal-backend, localhost port 18090. Preflight verifies the installed unit and default H2 path, rejecting overrides that would make the backup incomplete. Private environment files can hold application settings; an external database URL requires a different backup procedure.
A process lock serializes deployments. The candidate's CI-recorded Git ancestry must contain the currently deployed commit, preventing an older queued candidate from replacing a newer release. Artifacts are immutable by full source commit and checksum.
Before switching applications, the script publishes the existing static HTTP 503 maintenance page, verifies it publicly, stops systemd and verifies inactive or failed state with no main PID. It then copies the closed data directory into a private rollback bundle, records checksums and the matching application manifest, and synchronizes the files before advancing its durable journal. Startup and Flow initialization must succeed while public access remains blocked.
Publication intent is synchronized before removing the maintenance flag. Once this intent exists, recovery proceeds forward and preserves possible new bookings even if power loss makes the flag reappear. Earlier failures restore the database snapshot and its exact previous application. A failed restore leaves maintenance active and the service stopped. remote backend recover resumes from the journal. A deployment remains failed in CI even when its rollback succeeds.
Successful publication retains the current and one previous successful application, and one matching rollback bundle. Each attempt takes a fresh snapshot, so intervening bookings survive repeated failed upgrades. Old deployment-owned bundles are cleaned only after success. This is separate from the existing Hostsharing backups.
The reminder scheduler checks the static maintenance flag before delivery; see web-push-transport.md for its implemented runtime configuration. Active Flow clients receive a localized reconnection message referring to maintenance. Work drafts remain local as described in work.md.
Evidence so far
Fifteen operational tests pass, covering closed-file timing, two failed upgrades, failed rollback, corrupted backups, interrupted startup, interruption after publication, reappearing flags after simulated power loss, old candidate rejection and runtime overrides. Real Hostsharing preflight passed without stopping the service or changing data. The first actual attempt stopped before backup/migration because Java exits with code 143 after graceful shutdown on this host, leaving systemd in failed state with MainPID zero. The guard was corrected to accept a fully stopped failed unit, with a regression test that still rejects any live PID. Recovery restored the original application publicly before retrying.
Werkator built corrected commit 6e6daa1 successfully in 109 seconds. Its exact verified artifact was deployed on 2026-09-09. Public Today, work form and habit configuration rendered successfully with no browser errors. The default customer/project and two ordinary configurable habits were visible; no test work entries or habit counts were written to production.
Post-deployment inspection confirmed active service, current commit 6e6daa1, previous application aec192f, matching backup manifest and valid database/JAR checksums, exactly two release directories and one rollback bundle, no maintenance flag and no pending journal. The backup was copied after stopping the old application and before migration. Full operator restore acceptance and automatic CI deployment remain separate nodes.
Data preservation after initial setup
The operator confirmed successful initial account setup on 2026-09-09. All subsequent migrations must preserve existing account and tracking data, including shared guest records. The earlier permission to discard guest-phase data is revoked. Do not reset or recreate production databases. Use new Liquibase SQL changesets with explicit data-preserving transformations; do not rewrite applied changesets. Validate each schema/data migration against a populated predecessor and verify retained values and relationships.
Before migration, block writes and take the existing closed-file backup. Automatic pre-publication rollback restores the application together with that matching snapshot. Once access has reopened, never overwrite subsequent user writes with an older snapshot. Explicit user-requested record/account deletion remains a separate application operation.