clean

Career/Microlise/ESS ESP/ESP Glossary.md

@@ -0,0 +1,197 @@
+# 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.