# 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.