Joseph Doherty
61 lines
4.3 KiB
Markdown
61 lines
4.3 KiB
Markdown
# Deployment record — wonder-app-vd03 (prod single host) — 2026-08-20
|
||
|
||
Binary + schema upgrade of the single-host install at `wonder-app-vd03.zmr.zimmer.com`
|
||
(`E:\ApiInstall\ScadaBridge`; `ScadaBridge-Central` :8085, `ScadaBridge-Site`, `ScadaBridge-LDAP`;
|
||
ConfigDb = local SQL Server). Same release and recipe as the QA deploy earlier today
|
||
(`2026-08-20-wonder-app-vq03-vq04.md`). **Access path:** servecli SSH (:2222) was down and the
|
||
box has no psbridge, so everything ran from wonder-app-vq04 over **WinRM**
|
||
(`Invoke-Command -ComputerName wonder-app-vd03`) and the `E$` admin share, driven via psbridge on vq04.
|
||
|
||
| Item | Value |
|
||
|---|---|
|
||
| Build deployed | `main` @ **`a24fa38e`** (from `20f2ae05`, 2026-08-12; 250 commits). CLI `cli\` from `3eb7df74` → `a24fa38e`. |
|
||
| Headline change | Grouped connection bindings (Configure page rows from the flattened config + per-module Object apply; CLI `instance bind-module`) plus everything since 08-12. |
|
||
| Staging | `\\wonder-app-vd03\E$\psrem-stage\a24fa38e` (robocopy of vq04's unpacked release). |
|
||
| EF migrations applied | the same 6 as QA (`20260814235335` … `20260819201210`), idempotent delta script from `20260810100836_AddSmtpConfigurationTransport`, `sqlcmd -C -b -I` on the box. |
|
||
| New required config | `AuditLog:SiteWriter:DatabasePath` → `E:\ApiInstall\ScadaBridge\site\data\auditlog.db` added to `appsettings.Site.json`. |
|
||
| Data relocated | site audit SQLite moved from `C:\Windows\System32\auditlog.db` into `site\data\`. |
|
||
| Preserved | the box's three `appsettings*.json`, service registry environment, `central\data`, `site\data`. |
|
||
| DB backup | `ScadaBridge_pre-a24fa38e_20260820T163653.bak` (COPY_ONLY, SQL Server default backup dir on vd03) |
|
||
| Binary backup | `app.bak.20260820T163718`, `cli.bak.20260820T163718` |
|
||
|
||
### Verification
|
||
- `/health/ready` 200 Healthy: central (database, akka-cluster Up, 5/5 singletons) and site
|
||
(akka-cluster Up, localdb Healthy). No ERR/FTL after boot except the usual first-probe
|
||
`member status: Removed`; WRNs are the known EF `FirstOrDefault` and h2c notes.
|
||
- `/deployment/instances/1/configure` (Z28061): **270 data-sourced attributes in 8 groups**, all
|
||
bound, objects inferred (`Z28061`, `DelmiaReceiver_038`, `Left_002.DelmiaReceiver`,
|
||
`MESReceiver_023`, `Left_002`, `Right_002.DelmiaReceiver`, `MESReceiver_024`, `Right_002`),
|
||
`Test Bindings (270)`. Previously only the 16 direct attributes were shown.
|
||
|
||
### Observed, not a regression
|
||
- The site `/health/ready` `localdb` entry reports `replicationConnected:false` on this
|
||
unreplicated single node (`SiteLocalDbHealthCheck` reads the raw engine flag, unlike the
|
||
health report which is gated on `ReplicationIsConfigured`, register row 80). Unchanged code
|
||
since the previous build; cosmetic follow-up.
|
||
|
||
### Rollback
|
||
Stop Site + Central, rename `app` → `app.failed`, `app.bak.20260820T163718` → `app` (same for
|
||
`cli`), start Central then Site. Schema restore from the `.bak` only if needed (migrations are additive).
|
||
|
||
## 2. Hotfix `da0bfe2b` — 17:03 (same day)
|
||
|
||
Binary-only swap of `app\` to `main` @ **`da0bfe2b`** (MxGateway adapter: a graceful end of the
|
||
event stream — dashboard "close session" / graceful gateway shutdown — is now a disconnect and
|
||
triggers reconnect + re-subscribe; see the QA record §4 for the incident). No migrations, no
|
||
config change; `cli\` untouched. Same WinRM-from-vq04 path: robocopy of vq04's unpacked release
|
||
to `\\wonder-app-vd03\E$\psrem-stage\da0bfe2b` (1020 files), stop Site → Central, rename
|
||
`app` → **`app.bak.20260820T170309`**, copy stage, copy back the three `appsettings*.json`,
|
||
start Central → Site.
|
||
|
||
Verification: `:8085` and `:8084` `/health/ready` 200 Healthy; `Host.dll` ProductVersion
|
||
`1.0.0+da0bfe2b…`; site log 0 ERR/FTL after boot. The boot produced the same ~40 s of
|
||
`Instance … subscribing to 270 tags` retries with `Worker command AdviseSupervisory timed out`
|
||
that the 16:38 boot on `a24fa38e` did (3 instances × 270 tags advised against the local
|
||
MxAccessGw), tailing off to the same ~1–2/min background `gRPC call deadline exceeded` by 17:07
|
||
— not a regression. The new "event stream ended without a fault" warning has not fired (nothing
|
||
closed the session).
|
||
|
||
Rollback: stop Site + Central, rename `app` → `app.failed`, `app.bak.20260820T170309` → `app`,
|
||
start Central then Site.
|