dohertj2/scadalink-design
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Refine remaining components: Deployment Manager, Central UI, Site Event Logging, S&F

Browse Source 
Deployment Manager: add deployment concurrency rules (block same-instance, allow
parallel different-instance), per-site artifact deployment status, current-only
status persistence.

Central UI: specify Blazor Server framework, real-time push updates via SignalR
for debug view, health dashboard, and deployment status.

Site Event Logging: daily retention purge, paginated queries with 500-event default,
keyword search on message/source fields.

Store-and-Forward: clarify async best-effort replication to standby with acceptable
trade-offs on failover.
This commit is contained in:
Joseph Doherty
2026-03-16 08:48:33 -04:00
parent a540912782
commit 70e5ae33d5
4 changed files with 43 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
Component-DeploymentManager.md
View File

@@ -41,6 +41,26 @@ Engineer (UI) → Deployment Manager (Central)
└── 8. Update deployment status in config DB
```
## Deployment Concurrency
- **Same instance**: A deployment to an instance is **blocked** if a previous deployment to that instance is still in progress (waiting for site response). The UI shows the deployment is in progress and rejects the second request. This prevents conflicting state at the site.
- **Different instances**: Deployments to different instances can proceed **in parallel**, even at the same site. Each deployment tracks status independently. This supports the bulk "deploy all out-of-date instances" operation efficiently.
## System-Wide Artifact Deployment Failure Handling
When deploying artifacts (shared scripts, external system definitions, etc.) to all sites, each site reports success or failure **independently**:
- The deployment status shows a per-site result matrix.
- Successful sites are **not rolled back** if other sites fail.
- The engineer can retry failed sites individually (e.g., when an offline site comes back online).
- This is consistent with the hub-and-spoke independence model — one site's unavailability does not affect others.
## Deployment Status Persistence
- Only the **current deployment status** per instance is stored in the configuration database (pending, in-progress, success, failed).
- No deployment history table — the audit log (via IAuditService) already captures every deployment action with who, what, when, and result.
- The Deployment Manager uses current status to determine staleness (is this instance up-to-date?) and display deployment results in the UI.
## Deployment Scope
- Deployment is performed at the **individual instance level**.