phenix-cruise
Phenix Cruise vertical: a .NET Framework 4.8.1 MVC booking UI for cruise quotes plus modern .NET 10 gateway/content/Odysseus-ACL APIs backed by MongoDB cruise content.
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, javascript |
| Frameworks | ASP.NET MVC 5, ASP.NET Core 10, Carter, FluentValidation |
| Runtimes | .NET Framework 4.8.1, .NET 10 |
| Tests / CI | good / CI in place |
| Last commit | 2026-07-24 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Selling and quoting (system generated; curate in repo-owners.json to override) |
| Product area | Phenix |
| Hosted | AWS + on-prem Ships artefacts to both AWS and on-prem machines (see evidence below)
|
| Releases | 2 release pipeline(s): \commercial\cruise\cruise-gateway-api; \commercial\cruise\phenix-cruise-ui |
| Integration | rest, wcf, redis, jwt |
| Source | Open in Azure DevOps |
Risk flags
Each flag links to its glossary definition.
Dependencies in context
Entanglement
kernel Bound into the core by 2 mechanism(s).
- Pinning dependency: application-framework, phenix-feature-service, mail-service, mailtemplate-service
- Speaks WCF (client)
Detaches when its pinning dependencies are cut or multi-targeted (application-framework, phenix-feature-service, mail-service, mailtemplate-service); and when its WCF surface gains a modern interface or its WCF calls move to one.
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. Legacy web front end: session state and framework age make mixed-version fleets risky until state is externalised. Session already externalised to Redis (remote-session), which removes the biggest blocker.
- Consumes WCF contract packages: never take a breaking client bump mid-feature, and treat obsolete warnings as migration debt
- Serialized state or messages in flight (Redis or queues): new code must deserialize objects written by the previous version
- Feature flags come from phenix-feature-service (WCF-only): flag reads themselves are a legacy dependency to watch
- Session is externalised to Redis: keep it that way, and check session object compatibility between versions
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- 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.
- Audit serialized data: anything in Redis, queues or shared caches must deserialize cleanly across adjacent versions.
- Externalise any remaining session state so users can move between nodes mid-session without disruption.
- 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
Feasible after replatformingAppropriate, but the .NET Framework runtime has to go first; container work rides along with the replatform rather than preceding it.
- .NET Framework only runs on Windows; practical (Linux) containers need modern .NET
- Replatform to modern .NET first (see the recommended actions). Containerising then becomes routine.
- 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
Replatform phenix-cruise to modern .NET
Runs on .NET Framework 4.8.1, .NET 10, out of mainstream support. Blocked until stage 2 cuts: application-framework, phenix-feature-service, mail-service, mailtemplate-service.
Impact: Reduces the end-of-life runtime count
proposedAssessment notes
phenix-cruise
Purpose
The cruise vertical in one repo. Cruise.UI is the IIS-hosted MVC app (TC.Phenix.Cruise.UI.Web) for building cruise quotes inside Phenix (booking workflow, company configuration, mappers to the quote entity). Cruise.API is a modern rebuild: a Gateway API (/API/CruiseGateway), a CruiseContent API over Widgety cruise/ship/port content in MongoDB, and an anti-corruption-layer API for the Odysseus cruise platform.
Tech stack
Two generations side by side: the UI targets .NET Framework 4.8.1 (SDK-style csproj) with ASP.NET MVC, Autofac-era TC caching (Redis, multi-level, many TC.Cache.Specialised.* packages) and Redis session state; the APIs target .NET 10 with Carter minimal-API modules, FluentValidation, JWT bearer auth, MongoDB.Driver, AWS Systems Manager configuration, xUnit v3, Testcontainers/Mongo2Go/WireMock for tests, and a Dockerfile for the Odysseus ACL API.
Deployment
prod_application with 2 releases: build pipelines phenix-cruise-gateway-api and phenix-cruise-ui, release pipelines under \commercial\cruise\. Five YAML pipeline definitions in-repo (gateway, content, odysseus-acl, ui, client package) using shared azure-pipelines-templates; the content and ACL APIs do not yet appear in the traced release pipelines.
Dependencies
Very wide fan-out from the UI: cruise service WCF contract (phenix-cruise-service), quote (phenix-quote), feature service, company info, user accounts, exchange rates, teams, destination management, flights, mail and mail templates, direct stock, booking download, contact-centre service client, tax service and BackOffice integration packages, all over TC.ConnectionBroker. The APIs are much leaner (FluentResults, ConnectionBroker Mongo/Redis/Wcf, UserAccount client). External: Widgety cruise content feeds, the Odysseus cruise booking platform, New Relic, AWS Systems Manager.
Data stores
MongoDB CruiseContent database (Widgety-derived collections for cruises, ships, ports, operators, classifications) owned by the content API. Redis for the shared Phenix cache (CacheStorage=redis-dual) and remote session state in the UI.
Integration points
REST between UI, gateway and content/ACL APIs (JWT-secured); legacy WCF from the UI to the cruise service and other Phenix services; Redis for cache/session.
Code health
Strong test culture: nine test projects on the API side (unit, integration, Testcontainers-based) plus five on the UI side, with a coverage-report script. Actively developed (last commit 2026-07-24). README is mostly boilerplate with some Rider setup notes.
Modernisation risks
Medium: the API half is exemplary (.NET 10, tested, containerised), but the revenue-generating UI is still a .NET Framework 4.8.1 MVC app coupled to ~20 estate services and the Phenix IIS shell, so cruise cannot leave the legacy platform until that UI is rebuilt. The repo's split personality also means two build toolchains and dependency graphs to maintain.