119 lines
4.6 KiB
Markdown
119 lines
4.6 KiB
Markdown
# 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.
|