189 lines
6.3 KiB
Org Mode
Executable File
189 lines
6.3 KiB
Org Mode
Executable File
:PROPERTIES:
|
|
:ID: 82c3d447-d6d3-498e-9f66-aee60c752462
|
|
:END:
|
|
#+DATE: 2026-04-10
|
|
#+filetags: :esp:ess:microlise:question:
|
|
#+STARTUP: showall
|
|
#+title: ESP — Open Questions & TBC Items
|
|
|
|
* Overview
|
|
:PROPERTIES:
|
|
:RELATED: [[id:a6c345df-8db9-4538-b87e-0e72e2414905][ESP Deployment Pipeline — Index]]
|
|
:END:
|
|
|
|
These are items explicitly marked as TBC or not yet designed in the handover material. They represent real blockers or gaps that need to be resolved before the pipeline is complete. Use this file to track answers as they are determined.
|
|
|
|
* Q1 — What Is the Rollback Plan?
|
|
:PROPERTIES:
|
|
:STATUS: TBC
|
|
:PRIORITY: High
|
|
:END:
|
|
|
|
** The Question
|
|
If a deployment fails partway through (e.g. the dacpac succeeds but a service won't start), how do we restore the system to its pre-deployment state?
|
|
|
|
** Why It's Hard
|
|
- The database cannot be easily rolled back without a restore from backup
|
|
- Files may have been partially swapped
|
|
- Citrix sessions may have been killed already
|
|
|
|
** Things to Consider
|
|
- Mandatory pre-deployment backup of database AND application files
|
|
- Snapshot-based restore if the server supports it (e.g. VM snapshots)
|
|
- A dedicated "rollback" stage that the pipeline can call
|
|
- Whether rollback is always manual or can be automated
|
|
|
|
** Answer (Fill In When Known)
|
|
_Not yet determined._
|
|
|
|
* Q2 — What Is the Test Plan?
|
|
:PROPERTIES:
|
|
:STATUS: TBC
|
|
:PRIORITY: High
|
|
:END:
|
|
|
|
** The Question
|
|
How will the pipeline and scripts themselves be tested before being used against customer environments?
|
|
|
|
** Things to Consider
|
|
- Unit tests for Tier 3 functions using Pester
|
|
- Integration tests against a test environment (once available — see Issue 3)
|
|
- Dry-run mode where the pipeline goes through all steps but prompts instead of acting
|
|
- Staged rollout: run full pipeline against ROMAC DEV first before any other environment
|
|
|
|
** Answer (Fill In When Known)
|
|
_Not yet determined._
|
|
|
|
* Q3 — What Is the Final Scope?
|
|
:PROPERTIES:
|
|
:STATUS: TBC
|
|
:PRIORITY: Medium
|
|
:END:
|
|
|
|
** The Question
|
|
Will the pipeline eventually cover:
|
|
- All customer environments (not just ROMAC DEV)?
|
|
- Production environments?
|
|
- Environments hosted in ESS's own data centre (not Microlise's)?
|
|
|
|
** Current Scope
|
|
ROMAC DEV only, as an initial target.
|
|
|
|
** Answer (Fill In When Known)
|
|
_Not yet determined — pending business decision._
|
|
|
|
* Q4 — How Exactly Are Citrix Apps Deployed/Upgraded?
|
|
:PROPERTIES:
|
|
:STATUS: TBC
|
|
:PRIORITY: High
|
|
:END:
|
|
|
|
** The Question
|
|
What is the technical mechanism for upgrading a Citrix-delivered application?
|
|
|
|
** Working Assumption
|
|
A file copy to the Citrix server, with handling for the running executable being locked by active sessions.
|
|
|
|
** Things to Investigate
|
|
- Does Citrix use App Layering or Provisioning Services (PVS)? If so, the upgrade process is very different from a file copy
|
|
- Are there Citrix-native PowerShell cmdlets for managing published apps?
|
|
- How are locked executables handled — do sessions need to be fully terminated first, or is there a staging mechanism?
|
|
- Who at ESS has this knowledge?
|
|
|
|
** Answer (Fill In When Known)
|
|
_Not yet determined._
|
|
|
|
* Q5 — What Is the Manifest Structure?
|
|
:PROPERTIES:
|
|
:STATUS: TBC — needs design
|
|
:PRIORITY: High
|
|
:END:
|
|
|
|
** The Question
|
|
What does the manifest config file look like? What format, what fields, where is it stored?
|
|
|
|
** See Also
|
|
[[id:9bf19a8b-5581-4be8-9892-913c51df0128][ESP — The Manifest]] contains a proposed structure. This needs to be validated against actual deployment requirements and agreed by the team.
|
|
|
|
** Answer (Fill In When Known)
|
|
_Proposed in [[id:9bf19a8b-5581-4be8-9892-913c51df0128][ESP — The Manifest]] - not yet confirmed._
|
|
|
|
* Q6 — How Are Build Artifacts Mapped to Applications?
|
|
:PROPERTIES:
|
|
:STATUS: TBC
|
|
:PRIORITY: High
|
|
:END:
|
|
|
|
** The Question
|
|
Given that the ESP build produces a flat folder of DLLs, how do we determine which DLLs belong to which application?
|
|
|
|
** Things to Investigate
|
|
- Does the build process have any metadata or manifest about what it produced?
|
|
- Can the build pipeline be modified to output per-application folders?
|
|
- Is there existing documentation from ESS about which files belong where?
|
|
- Can we infer the mapping from the existing install directories on ROMAC DEV?
|
|
|
|
** Answer (Fill In When Known)
|
|
_Not yet determined._
|
|
|
|
* Q7 — Full Detail of Tier 2 & Tier 3 Functions Needed
|
|
:PROPERTIES:
|
|
:STATUS: TBC
|
|
:PRIORITY: Medium
|
|
:END:
|
|
|
|
** The Question
|
|
The handover defines the architecture but not the complete list of all Tier 2 logic and Tier 3 functions needed for a full deployment. What is the complete list?
|
|
|
|
** Approach to Resolve
|
|
- Work through each deployment stage manually with a human operator
|
|
- Document every step they perform
|
|
- Each manual step maps to at least one Tier 3 function
|
|
- Aggregate these into a complete function inventory
|
|
|
|
** Answer (Fill In When Known)
|
|
_Ongoing — to be determined through walkthroughs with ESS/ops._
|
|
|
|
* Q8 — What Are All the Prerequisites?
|
|
:PROPERTIES:
|
|
:STATUS: TBC — described as "extensive"
|
|
:PRIORITY: Medium
|
|
:END:
|
|
|
|
** The Question
|
|
The PREREQUISITES stage is described as checking "an extensive list" of prerequisites, but the full list has not been documented.
|
|
|
|
** Things to Investigate
|
|
- What software must be installed on each server type (app server, DB server, Citrix server)?
|
|
- What Windows configuration must be in place?
|
|
- What network connectivity is required?
|
|
- What service accounts / permissions must exist?
|
|
- What environment labels/flags are needed?
|
|
|
|
** Answer (Fill In When Known)
|
|
_Not yet documented._
|
|
|
|
* Q9 — How Should Secrets Be Managed?
|
|
:PROPERTIES:
|
|
:STATUS: Not addressed in handover
|
|
:PRIORITY: High
|
|
:END:
|
|
|
|
** The Question
|
|
The manifest and scripts will need credentials (DB passwords, server credentials, service account passwords). Where do these live and how are they accessed securely?
|
|
|
|
** Options
|
|
- AzDO secret pipeline variables
|
|
- Azure Key Vault (referenced by name in manifest, retrieved at runtime)
|
|
- Windows Credential Manager on a self-hosted agent
|
|
- Encrypted secrets in the repo (not recommended)
|
|
|
|
** Answer (Fill In When Known)
|
|
_Not yet determined._
|
|
|
|
* Resolved Questions
|
|
|
|
| # | Question | Resolved Date | Answer |
|
|
|---+-----------------------+---------------+--------|
|
|
| | _(none resolved yet)_ | | |
|