vault/Career/Microlise/ESS ESP/ESP Glossary.md

---
note type:
  - ess
  - note
date: 2026-06-03
done: true
---
# Overview

Reference glossary for all technical and project-specific terms used across the ESP deployment pipeline project. Alphabetically ordered.

# A

## Agent (AzDO)

The machine that executes an AzDO pipeline. Can be **Microsoft-hosted** (a fresh Azure VM for each run) or **self-hosted** (a persistent machine you manage).
For deploying to customer servers, a self-hosted agent is required to have network access to those servers.

## Artifact (Build)

The output of a build pipeline — typically compiled binaries, DLLs, config files, etc. packaged and stored so a deployment pipeline can consume them.
The ESP build artifact is currently a flat folder of DLLs. See [[ESP Known Issues and Risks]]

## AzDO / Azure DevOps

Microsoft's DevOps platform. Provides Repos (Git), Pipelines (CI/CD), Boards (work tracking), and Artifacts (package storage). The ESP pipeline lives here.

# B

## BACPAC

A SQL Server package format that includes both schema **and** data. Useful for backup/restore. Contrast with Dacpac (schema only).

## Build Pipeline

An AzDO pipeline that compiles source code and produces a build artifact. The ESP build pipeline is `ESS.esp Main Build`.

# C

## CI/CD

**Continuous Integration / Continuous Delivery (or Deployment)**. The practice of automatically building, testing, and deploying software whenever changes are made. AzDO pipelines implement this.

## Citrix

A technology platform that delivers desktop applications to users remotely. The application runs on a Citrix server; users see and interact with it via the Citrix Workspace client. Three ESP applications (VPlanner, VPlannerAdmin, ImportApp) are delivered this way.

## Cycle Checks

Post-deployment validation checks for ESP that involve navigating through the Citrix application UI to verify the system is functioning correctly. These are extensive and difficult to automate. See [[ESP Deploy Stages]].

# D

## Dacpac

**Data-tier Application Package**. A `.dacpac` file that represents the desired schema of a SQL Server database. Deployed using `sqlpackage.exe`, which calculates the difference between desired and actual schema and applies it. See [[ESP Database]].

## `dacpacReady`

A flag in the manifest (see [[ESP Manifest]]) that indicates whether a customer's database has been manually aligned to be compatible with the dacpac. Must be `true` before the pipeline will attempt database deployment.

## Deploy Pipeline

The AzDO pipeline responsible for deploying ESP to customer environments. Currently: `ESS.esp Deploy`. This is the primary pipeline your team owns.

## DLL

**Dynamic Link Library**. A compiled Windows binary file (`.dll`) containing reusable code. Windows Services and other Windows applications are composed of DLLs. Deploying a new version means replacing old DLLs with new ones.

# E

## Environment

In the context of ESP, an environment is a specific deployment target for a customer (e.g. DEV, TEST, PROD). A customer may have multiple environments. Each environment has its own manifest.

## ESP

The application suite built by ESS. Delivered to customers on a per-customer basis. Contains databases, Windows Services, and Citrix applications. See [[ESP Applications]].

## ESS

The company that built ESP. Formerly had a larger engineering team; now reduced. Has a data centre of their own where some customer instances are hosted.

## EspBroker

The SQL Server database used by ESP. The only database in the suite currently. Deployed via dacpac.

# G

## Grace Period

In the context of Citrix deployment: the time given to active Citrix users to save their work and quit before their session is forcibly terminated to allow the upgrade to proceed.

# J

## Job (AzDO)

A unit of work within an AzDO pipeline stage. Each job runs on a single agent. A stage can have multiple parallel jobs.

# L

## Layer / Tier

The architectural layers in the PowerShell script design. Tier 1 = entry point; Tier 2 = orchestration; Tier 3 = isolated worker functions. See [[ESP Scripts]].

# M

## Manifest

A configuration file defining a specific customer environment. Used by the deployment scripts to know what to deploy, where, and how.
See [[ESP Manifest]].

## Microlise

The company the team works for. The ESP pipeline project is being done by Microlise engineers to assist ESS.

## Module (PowerShell)

A packaged collection of PowerShell functions, stored in a `.psm1` file. Modules are loaded with `Import-Module`. The Tier 2 and Tier 3 scripts are structured as modules.

# P

## Pester

The standard PowerShell testing framework. Used for writing unit tests for PowerShell functions. Particularly useful for testing Tier 3 functions in isolation.

## Pipeline (AzDO)

An automated workflow defined in YAML that can build, test, and deploy software. Triggered by events (code pushes, schedules, manual runs).

## PowerShell

Microsoft's scripting language and shell, built on .NET. Used for all deployment scripting in this project.

## Prerequisites

The PREREQUISITES deployment stage — checks that the target environment has all required software, configuration, and connectivity before deployment begins.

## `.psm1`

The file extension for a PowerShell module file.

# R

## Remote Session (PowerShell)

A PowerShell remoting session to another machine, created with `New-PSSession`. Allows you to run PowerShell commands on a remote server. Required for managing Windows Services and files on customer servers.

``` powershell
$session = New-PSSession -ComputerName "ROMAC-DEV-APP01"
Invoke-Command -Session $session -ScriptBlock { Get-Service }
```

## ROMAC DEV

The initial target customer environment for the pipeline. ROMAC is the customer name; DEV is the environment tier.

# S

## Schema (Database)

The structure of a SQL Server database — its tables, columns, indexes, constraints, stored procedures, etc. The dacpac encodes the desired schema.

## Self-Hosted Agent

An AzDO agent running on a machine you manage (rather than a Microsoft-managed Azure VM). Required for this project to have network access to customer servers.

## `sqlpackage.exe`

Microsoft's command-line tool for deploying dacpac files to SQL Server.

## Stage (Deployment)

One of the five phases of the ESP deployment: VALIDATE, PREREQUISITES, PREDEPLOY, DEPLOY, POSTDEPLOY. Each can be run independently. See [[ESP Deploy Stages]].

## Stage (AzDO Pipeline)

A high-level grouping within an AzDO YAML pipeline, containing jobs. Not the same as a deployment stage — naming coincidence.

# T

## Team Ludo

The Microlise team that preceded your team on this project. They built the ESP suite in AzDO, started deployment work, and built the dacpac. Now reassigned to paid customer work.

## Tier 1 / 2 / 3

See **Layer / Tier** above and [[ESP Scripts]].

## TMC

Another Microlise product, referenced in the handover as a comparison point for how ESP works (per-customer deployment, multiple environments, etc.).

# W

## Windows Service

A background process that runs on a Windows server, managed by the Windows Service Control Manager. Can be started, stopped, and queried via PowerShell. Six ESP services exist: DLService, EmailService, ExPlService, MISService, OutboundService, ULService.

# Y

## YAML

**YAML Ain't Markup Language**. A human-readable data format used for AzDO pipeline definitions. Stored in the repo as a `.yml` file.