8.1 KiB
Executable File
ESP — Glossary
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 & 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 — Deployment 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 & Dacpac.
dacpacReady
A flag in the manifest (see ESP — The 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 — PowerShell Script Architecture.
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 — The 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.
$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 — Deployment 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 — PowerShell Script Architecture.
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.