clean

2026-06-02 14:26:45 +01:00
parent cfa8867ca1
commit 6e65fa187c
73 changed files with 1331 additions and 190 deletions
--- a/Career/Microlise/ESS
+++ b/Career/Microlise/ESS
@@ -0,0 +1,118 @@
+# What Is the Manifest?
+
+The manifest is a **configuration file** that describes a specific customer environment. The deployment scripts read the manifest to understand **what** to deploy, **where**, and **how**.
+
+There will be one manifest per customer/environment combination, for example:
+
+  - `ROMAC_DEV.json` (or `.yaml`, `.psd1` — format TBC)
+  - `ROMAC_PROD.json`
+  - `ACMECORP_DEV.json`
+
+# Why the Manifest Matters
+
+Without a manifest, the scripts would have no way of knowing:
+
+  - Which server(s) to connect to
+  - Which apps this customer actually uses
+  - What credentials to use
+  - What version is being deployed
+  - What environment-specific configuration to apply
+
+It is the **single source of truth** for a deployment. Tier 1 loads it, validates it, and passes it to Tier 2. Tier 2 extracts values from it and passes those to Tier 3.
+
+# Design Status
+
+The manifest **structure has not yet been fully designed**. This is an open work item. See [[ESP OQ]] for a list of design questions to resolve.
+
+What follows is a **proposed structure** based on what the scripts will need.
+
+# Proposed Manifest Structure
+
+``` json
+{
+  "customer": "ROMAC",
+  "environment": "DEV",
+  "version": "3.2.1",
+
+  "servers": {
+    "appServer": "ROMAC-DEV-APP01",
+    "dbServer":  "ROMAC-DEV-DB01",
+    "citrixServer": "ROMAC-DEV-CTX01"
+  },
+
+  "database": {
+    "name": "EspBroker",
+    "dacpacReady": false
+  },
+
+  "windowsServices": {
+    "DLService":       { "enabled": true,  "installPath": "C:\\ESP\\DLService" },
+    "EmailService":    { "enabled": true,  "installPath": "C:\\ESP\\EmailService" },
+    "ExPlService":     { "enabled": false },
+    "MISService":      { "enabled": true,  "installPath": "C:\\ESP\\MISService" },
+    "OutboundService": { "enabled": true,  "installPath": "C:\\ESP\\OutboundService" },
+    "ULService":       { "enabled": false }
+  },
+
+  "citrixApps": {
+    "VPlanner":      { "enabled": true,  "installPath": "C:\\ESP\\VPlanner" },
+    "VPlannerAdmin": { "enabled": true,  "installPath": "C:\\ESP\\VPlannerAdmin" },
+    "ImportApp":     { "enabled": false }
+  },
+
+  "citrix": {
+    "notificationMinutes": 15,
+    "sessionKillGracePeriodMinutes": 5
+  }
+}
+```
+
+# Key Fields to Define
+
+| Field                       | Purpose                                                     |
+| --------------------------- | ----------------------------------------------------------- |
+| `customer`                  | Identifies the customer                                     |
+| `environment`               | Identifies the environment (DEV/TEST/PROD)                  |
+| `version`                   | Version of ESP being deployed                               |
+| `servers.*`                 | Hostnames/IPs of servers to connect to                      |
+| `database.dacpacReady`      | Flag to indicate if DB is in a state for dacpac deployment  |
+| `windowsServices.*.enabled` | Whether this customer uses this service                     |
+| `citrixApps.*.enabled`      | Whether this customer uses this Citrix app                  |
+| `citrix.*`                  | Citrix-specific config (notification timing, grace periods) |
+
+# Manifest Validation (VALIDATE Stage)
+
+The VALIDATE stage (see [[ESP Deploy Stages]]) loads the manifest and checks it is well-formed before any deployment activity. Things to validate:
+
+  - All required fields are present
+  - Server names are resolvable/pingable
+  - `version` matches available build artifacts
+  - `dacpacReady` flag prevents DB deployment if false
+  - No conflicting settings (e.g. test and prod on same server without flag)
+
+# Manifest Location and Storage
+
+Where manifests should live is TBC, but candidates include:
+
+  - A dedicated folder in the AzDO repo (versioned with the scripts)
+  - A separate config repo
+  - An external config store (Azure App Configuration, Key Vault, etc.)
+
+Sensitive values (passwords, connection strings) should **never** be in the manifest file in plaintext — they should reference a secret store.
+
+# Per-Customer App Lists
+
+Because not all customers use all apps, the manifest is the mechanism that drives per-customer deployment. Tier 2 scripts iterate over enabled apps:
+
+``` powershell
+foreach ($service in $manifest.WindowsServices.GetEnumerator()) {
+    if ($service.Value.Enabled) {
+        Stop-WindowsService -ServiceName $service.Key `
+                            -ServerName  $manifest.Servers.AppServer
+    }
+}
+```
+
+# Environments on the Same Server
+
+The handover document flags that some customers may have TEST and PROD on the same physical server. The manifest must account for this — likely via distinct install paths per environment and explicit environment tagging to prevent accidental cross-environment deployment.