phenix-postbookingactivities
.NET 8 API plus Angular 8 SPA monorepo for cancelling in-resort activities on a booking, fanning out cancellation-terms and cancel calls to the Phenix product gateways.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | csharp, typescript |
| Frameworks | ASP.NET Core 8, Angular 8, Polly |
| Runtimes | .NET 8 |
| Tests / CI | none / CI in place |
| Last commit | 2025-03-04 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Bookings and fulfilment (system generated; curate in repo-owners.json to override) |
| Product area | Phenix |
| Hosted | On-prem Deployed to our own machines
|
| Releases | 2 release pipeline(s): \commercial\phenix-postbooking-api; \commercial\zz obsolete by monorepo phenix-postbookingactivities-ui |
| Integration | rest |
| Source | Open in Azure DevOps |
Risk flags
Each flag links to its glossary definition.
Dependencies in context
Entanglement
loosely attached Bound into the core by 1 mechanism(s).
- Pinning dependency: application-framework
Detaches when its pinning dependencies are cut or multi-targeted (application-framework).
Depends on / used by
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
Needs workFeasible through the Workflow Engine's rolling drain, but real preparation is needed: dual-version discipline, better tests, or schema care before at-will release is sensible. No automated tests yet.
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Route deployments through the Workflow Engine's automated drain, deploy, health-check, return cycle (the path proven by the first automated production run in mid-2026).
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Ready to containeriseModern runtime, no hosted legacy transport: this service can follow the estate's proven container path (Dockerfile, shared pipeline template, ECS via Terraform).
- Add a Dockerfile and make the app read all configuration from environment variables and the secrets manager, never from machine-local files.
- Log to stdout and expose a health check endpoint so ECS can supervise it.
- Adopt the shared ci.yml pipeline template with the container parameters (awsRegion, containerAfterBuild, ecsTerraformRepo), which is exactly how the estate's existing AWS services deploy.
- Define the service in the Terraform repo, deploy to a non-production environment, then shift traffic and disarm the deployment-group release pipeline.
Recommended actions
No specific actions for this repo. It either needs only normal maintenance, or its work is covered by an estate-level action. See the full programme.
Assessment notes
phenix-postbookingactivities
Purpose
Monorepo for the Phenix "post-booking activities" feature: a thin ASP.NET Core API (Phenix.PostBooking.Api) exposing GetCancellationTerms / CancelBooking per product type (accommodation, attractions, car hire, ground handling, point-to-point), and an Angular SPA served under /sites/Phenix/PostBookingActivities/ that drives it.
Tech stack
API: C# on .NET 8, SDK-style projects with shared Directory.Build.props, FluentValidation, API versioning, Swashbuckle, PhenixAuth authentication scheme, Polly retry/circuit-breaker wrapping every facade call, TC.ConnectionBroker.Api named HTTP clients. UI: Angular 8 with @tc/angular, @tc/web-styles and ngx-translate, built via Angular CLI.
Deployment
Included as prod_application with 2 releases. YAML pipelines exist for both API and UI (shared azure-pipelines-templates from InternalOSS); build pipelines phenix-postbooking-api and phenix-postbookingactivities-ui CI (an older UI pipeline is marked "zz obsolete by monorepo"). Release pipelines under \commercial\: phenix-postbooking-api and the obsolete UI one. New Relic app names configured per environment.
Dependencies
Internal: fans out over ConnectionBroker HTTP targets to Accommodation (phenix-accommodation), Attractions (phenix-attractions), CarHireGateway (phenix-carhire) and P2PGateway (phenix-p2p); packages from tc-connectionbroker, tc-exceptions and TC.Phenix.ApplicationFramework (application-framework), plus TC.Phenix.ClientApiLibrary. External: New Relic APM.
Data stores
None — the API is a stateless orchestrator over the product gateway APIs; no connection strings in any appsettings file.
Integration points
REST only: inbound versioned REST API consumed by its own SPA, outbound REST to the Phenix product gateways.
Code health
The xUnit test project contains a single DummyTest placeholder, and the UI has only four scaffolded karma specs — effectively no test coverage. StyleCop/rulesets and analyser config are in place, YAML CI exists, and the repo was last touched 2025-03-04. The root appsettings.json is UTF-16 encoded, an odd quirk.
Modernisation risks
Low: the API is already on .NET 8 with modern patterns (Polly resilience, YAML pipelines). Residual risks are the absence of real tests and the Angular 8 frontend (out of LTS since 2020), which will need upgrading; the obsolete UI release pipeline suggests deployment wiring should be tidied up.