7.7 KiB
Executable File
Joined team Shackleton on <2026-04-07 Tue>, who are now overseeing the deployment process for ESS applications.
AI generated overview of ESP
What's the Big Picture?
Your team is building an automated deployment pipeline for a software suite called ESP (made by a company called ESS). Right now, deploying ESP to customer environments is done manually - someone has to go through a checklist and do things by hand. That's slow, error-prone, and relies on people who are leaving the company. The goal is to automate all of that.
The pipeline will live in Azure DevOps (AzDO) - Microsoft's platform for CI/CD (building and deploying software automatically).
Why Is This Happening Now?
The engineers who originally built and understood ESP have mostly left ESS. The ones who remain are tied up on paid customer work. So this task was handed off to a Microlise team (Team Ludo) who got the ball rolling - they got ESP building in AzDO and started on deployment. Now Ludo have been pulled onto other work too, and your team has inherited it.
So you're the third team to touch this. Expect some rough edges and gaps in knowledge.
What Is ESP, Exactly?
ESP is a suite of applications sold to customers. Think of it like a product bundle - each customer gets the apps they actually need (not every customer gets everything). It's delivered and runs on the customer's environment, which means:
- You're deploying to their servers, not yours
- Different customers have different sets of apps installed
- Some customers might have test and production on the same server - which is a headache, because you have to be careful not to accidentally deploy to prod when you meant test
The apps in the suite are:
- One database -
EspBroker(SQL Server database) - Six Windows Services - background processes that run on a server (DLService, EmailService, etc.)
- Three Citrix Applications - desktop apps delivered via Citrix (VPlanner, VPlannerAdmin, ImportApp). Citrix is a technology that streams apps to users remotely, like a remote desktop but per-app.
What Is the Pipeline Actually Going to Do?
The pipeline will run PowerShell scripts that walk through a deployment in stages. Think of it like a structured checklist that will eventually become fully automated. The stages are:
| Stage | What it does |
|---|---|
| Validate | Loads and checks the manifest (config file describing the environment) |
| Prerequisites | Checks the target server has everything it needs before you touch it |
| Predeploy | Copies the new version's files to the server and configures them |
| Deploy | The actual upgrade - stops services, swaps old files for new, starts back up |
| Postdeploy | Checks everything came back up healthy |
You can run any combination of these stages, so for example you might just run Validate to check your config is right, without actually deploying anything.
The Script Architecture (This Is Important)
The scripts are designed in three tiers, like a layered cake:
Tier 1 - The Entry Point You call one script (e.g. Invoke-Deployment.ps1) and tell it the customer, environment, and which stages to run. It loads the manifest, loads all the modules, then hands off to Tier 2.
Tier 2 - The Orchestrator One script per stage (PreDeployment, Deployment, etc.). This is the "brain" - it decides what needs to happen and in what order, then calls Tier 3 to actually do it. It never does anything directly itself.
Tier 3 - The Workers Small, self-contained functions that each do one thing - stop a Windows service, run a SQL query, copy a file, etc. They know nothing about ESP specifically. They just take parameters and do the job. This is useful because you can test them in isolation.
Why this structure matters for you: Right now, many Tier 3 functions are essentially placeholders - instead of actually doing something, they prompt a human to do it manually. The plan is to replace those manual prompts with real automation over time. So initially the pipeline is more of a guided checklist than true automation.
The Manifest - What Is That?
A manifest is a config file that describes a specific customer's environment - which apps they have, what servers they're on, credentials, etc. The idea is that you have one manifest per customer/environment combo (e.g.ROMAC DEV), and the scripts read that to know what to do. The manifest design isn't fully defined yet, which is one of the open items.
The Dacpac - What's That?
A dacpac is a packaged SQL Server database schema. Instead of writing raw SQL migration scripts, you describe what the database should look like, and the dacpac tool works out what changes to make to get there. Team Ludo built one for the ESP database.
The big problem: The existing customer databases are in an inconsistent state - they've drifted from the official schema over time (probably from manual fixes and patches). Before you can deploy via dacpac, someone will need to manually clean up each database to get it into a consistent state. Until that's done, the database deployment step can't be automated.
The Known Pain Points You Should Be Aware Of
These are the things most likely to cause your team grief:
-
Inconsistent databases - Can't use the dacpac until each customer's DB is manually fixed first. The pipeline needs to detect this and fail gracefully rather than making things worse.
-
The build artifact is a mess - The ESP build produces a huge folder of DLLs all jumbled together, rather than neatly separated per application. Your scripts will need to figure out which files belong to which app.
-
No test environment - You don't have a safe sandbox to practice deployments on. Any deployment you run is against a real customer environment. This is a significant risk.
-
Can't run locally - Licensing restrictions mean you can't run ESP on your own machine to test things. Everything has to happen on the actual servers.
-
Citrix is complicated - Deploying the Citrix apps requires notifying users, waiting for them to quit, killing sessions if they don't, and then doing the upgrade. The exact mechanism for the upgrade itself (how do you actually swap the Citrix app?) is still TBC.
-
Cycle checks - Post-deployment checks involve navigating through the Citrix UI to verify things work. That's very hard to automate.
What's Still Not Decided
Several important things are still open:
- Rollback plan - If a deployment goes wrong, how do you undo it? Not defined yet.
- Test plan - How will you test the pipeline itself?
- Citrix deployment method - Believed to be a file copy but not confirmed
- Manifest structure - What does the config file actually look like?
- Full scope - Will this eventually cover production and ESS's own data centre too?
What Should You Focus On First?
To provide real value quickly, I'd suggest getting comfortable with:
- Azure DevOps YAML pipelines - understand how they're structured and how they trigger scripts
- PowerShell scripting - the whole deployment mechanism is PowerShell
- The existing Ludo work - look at the existing pipeline runs and deploy scripts linked in the document before writing anything new
- The manifest concept - helping define what that config file looks like is impactful foundational work
- The dacpac situation - understanding which customer databases need manual cleanup before automation can work