ESP — The Manifest

What Is the Manifest?
Why the Manifest Matters
Design Status
Proposed Manifest Structure
Key Fields to Define
Manifest Validation (VALIDATE Stage)
Manifest Location and Storage
Per-Customer App Lists
Environments on the Same Server

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 — Open Questions & TBC Items for a list of design questions to resolve.

What follows is a proposed structure based on what the scripts will need.

Proposed Manifest Structure

{
  "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 — Deployment 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:

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.

5.2 KiB Raw Blame History