Tailspin Logistics - Untangling ALM and a 24-Hour Hotfix
Tailspin Logistics runs a model-driven claims app across Dev, UAT and Prod. An independent software vendor supplies a managed base solution; Tailspin adds custom tables and flows on top. Twelve makers all build in the single Dev environment. Over 18 months, administrators made "quick fixes" directly in Prod and exported unmanaged solutions to UAT. Now a P1 defect must be fixed in Prod within 24 hours while a six-week feature build is half-finished in Dev. The solution includes a SharePoint connection reference and an environment variable pointing to a SQL endpoint that differs per environment. A recent import to UAT failed with "missing dependency" and left the environment in a partially upgraded state.
1. Define the target ALM model and how you get Prod back to a trustworthy baseline.
Read the worked answer
Target model:
- Dev is the only place unmanaged solutions exist. UAT and Prod receive managed solutions only.
- Introduce layering: vendor base solution (managed, never modified) → "Tailspin Core" (custom tables, security roles, environment variables) → one feature solution per workstream. Layers deploy in dependency order and can ship independently.
- Separate environments per purpose, and a dedicated environment for the reconciliation work so Dev is not disturbed.
- Automated pipelines (Power Platform Pipelines or Azure DevOps with the Power Platform Build Tools) using a service principal, with a per-environment deployment settings file.
Get Prod to baseline (one-time effort):
- Snapshot Prod and UAT.
- In a scratch environment, install the vendor base plus the last known release, then import the unmanaged customisations exported from Prod so the customisation set is materialised as a solution.
- Export that as managed and deploy it to Prod once, so from that point Prod is managed-only.
- Freeze direct Prod changes and compare deployed solution versions against source control to detect drift.
Accept that this reconciliation is a project, not a deploy - schedule it after the P1 is handled.
2. Describe the 24-hour hotfix path without corrupting the in-flight feature work.
Read the worked answer
Do not export anything from Prod and do not touch the half-finished feature branch.
- Identify the exact source version currently deployed to Prod (from the pipeline history or the deployed solution version number).
- Branch from that tag, not from Dev main.
- Make the minimum change; no refactoring, no opportunistic fixes.
- Produce a patch of the managed solution deployed in Prod (clone the solution as a patch). A patch installs as a child of that specific parent version, so it will not pull in the in-flight feature work - but it must be merged back later, and it only applies to that parent version.
- Deploy to UAT, run the regression tests for the claims process, then deploy the same artefact to Prod.
- Merge the fix into the Dev mainline so the next full upgrade carries it, and plan to consolidate the patch in the next release.
If the fix requires schema changes that conflict with the in-flight feature, the honest answer may be a rollback of the feature deployment date - say so rather than improvising in Prod. Also record a rollback plan (previous managed solution version and a database backup) before touching Prod.
3. Why did the UAT import fail, and how do connection references and environment variables change the import process?
Read the worked answer
"Missing dependency" almost always means the solution does not carry, or cannot find, a component it references - most often the parent managed solution at the required version, a missing publisher/prefix match, or a component that lives in another solution in the source environment. Deploy in strict order: vendor base first, then Core, then feature solutions, and make the base a prerequisite in the pipeline.
Connection references are placeholders that must be bound to a real connection in the target environment at import time. Exporting without them means flows import broken; also ensure the importing identity can create connections and that the connector is not blocked by a DLP policy in that environment.
Environment variables carry the per-environment SQL endpoint. Export the definition with the solution and supply the value through the deployment settings file per environment - never hardcode Prod values in Dev.
Avoid partial upgrades: use staged upgrades for versions with schema deletions, always take a backup immediately before a major deployment, and test the upgrade path in a copy of Prod before the real window. Partial states are recoverable by re-importing the previous managed version; keep that artefact on hand.