# Overview

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?

## 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)

<span class="underline">Not yet determined.</span>

# Q2 — What Is the Test Plan?

## 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)

<span class="underline">Not yet determined.</span>

# Q3 — What Is the Final Scope?

## 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)

<span class="underline">Not yet determined — pending business decision.</span>

# Q4 — How Exactly Are Citrix Apps Deployed/Upgraded?

## 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)

<span class="underline">Not yet determined.</span>

# Q5 — What Is the Manifest Structure?

## The Question

What does the manifest config file look like? What format, what fields, where is it stored?

## See Also

[[ESP Manifest]] contains a proposed structure. This needs to be validated against actual deployment requirements and agreed by the team.

## Answer (Fill In When Known)

<span class="underline">Proposed in [ESP — The Manifest](id:9bf19a8b-5581-4be8-9892-913c51df0128) - not yet confirmed.</span>

# Q6 — How Are Build Artifacts Mapped to Applications?

## 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)

<span class="underline">Not yet determined.</span>

# Q7 — Full Detail of Tier 2 & Tier 3 Functions Needed

## 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)

<span class="underline">Ongoing — to be determined through walkthroughs with ESS/ops.</span>

# Q8 — What Are All the Prerequisites?

## 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)

<span class="underline">Not yet documented.</span>

# Q9 — How Should Secrets Be Managed?

## 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)

<span class="underline">Not yet determined.</span>

# Resolved Questions

| \# | Question                                           | Resolved Date | Answer |
| -- | -------------------------------------------------- | ------------- | ------ |
|    | <span class="underline">(none resolved yet)</span> |               |        |
