phenix-feature-service
WCF service and client NuGet packages for managing and checking Phenix feature flags at company and user level, backed by stored procedures in the shared Phenix database.
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 |
| Frameworks | WCF |
| Runtimes | .NET Framework 4.7.2, .NET Framework 4.6.2, .NET Standard 2.0 |
| Tests / CI | none / CI in place |
| Last commit | 2025-11-21 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Platform services (system generated; curate in repo-owners.json to override) |
| Product area | Phenix |
| Hosted | On-prem Deployed to our own machines
|
| Releases | 1 release pipeline(s): phenix-feature-service WCF |
| Integration | wcf, sqlserver |
| Source | Open in Azure DevOps |
Risk flags
Each flag links to its glossary definition.
Dependencies in context
Entanglement
kernel Bound into the core by 3 mechanism(s).
- Pinning dependency: phenix-feature-service
- Speaks WCF (host)
- Shares core database sqlserver:Phenix
Detaches when it is itself a binding point: unpinning it releases its consumers; and when its WCF surface gains a modern interface or its WCF calls move to one; and when the shared database group it belongs to gains an owned API or completes schema separation (sqlserver:Phenix).
This repo is itself a binding point: see what cutting it unlocks.
Capability duplication
Part of the Feature flags family (retire): WCF-only on .NET Framework 4.7.2, no tests, 25 dependents; replace with a modern feature flag service
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
Not applicableNot a deployed service (libraries, database definitions, desktop apps) or a retirement candidate not worth the investment. Retirement or consolidation candidate; do not invest in ZDD adoption.
SQL Server exit
Retire insteadThis repo is a retirement or consolidation candidate. Do not invest in a database migration; execute the retirement and the SQL Server dependency disappears with it.
Containerisation
Retire insteadThis repo is a retirement or consolidation candidate; containerising it would be investment in something we intend to switch off.
Recommended actions
Retire phenix-feature-service
WCF-only on .NET Framework 4.7.2, no tests, 25 dependents; replace with a modern feature flag service. Part of the Feature flags consolidation: Introduce one modern feature flag service, migrate the 25 consumers of phenix-feature-service to it, retire tc-features, and remove the hardcoded toggle maps as their hosts are modernised.
Impact: A migration never paid for, a pipeline decommissioned and an attack surface removed
proposedReplace phenix-feature-service with a modern feature flag service
WCF-only feature flags with 25 dependents and no tests. Replacing it releases every consumer whose only legacy tie is a flag lookup.
Impact: Highest leverage in the programme: releases consumers without touching them
proposedRaise the test floor on phenix-feature-service
28 systems depend on it and test coverage is absent. Chokepoints carry good tests before they are changed.
Impact: De-risks change for 28 dependent systems
proposedAssessment notes
phenix-feature-service
Purpose
The Phenix feature-flag service. A WCF service (PhenixFeatureService.svc) exposes feature checks and management operations; the repo also publishes the client-side NuGet packages TC.Phenix.Feature (the IFeatureService abstraction with HasFeatureAsync company/user/effective-date semantics), TC.ServiceContract.PhenixFeature, TC.Phenix.Feature.Messages, entities and managers. Feature flags gate behaviour across many Phenix apps (booking UI, contact-centre, components API all consume it).
Tech stack
C# .NET Framework: the WCF host targets 4.7.2 (old-style csproj, IIS-hosted .svc with wsHttpBinding and netTcpBinding high-performance bindings), contract/entity/message packages target 4.6.2, managers 4.7.2, and the TC.Phenix.Feature client abstraction is netstandard2.0. Data access is raw SqlConnection/stored procedures (e.g. PersonCompanyPhenixFeature_SELECT) through TC.ConnectionBroker. Nerdbank GitVersioning and per-environment Web.*.config transforms.
Deployment
One release pipeline (phenix-feature-service WCF, release_count 1) from the matching build pipeline. A YAML pipeline (build-wcf.yml) builds both solutions with the shared azure-pipelines-templates repo — notably it excludes an /src/api/* path that does not exist in the repo, hinting at a planned/abandoned REST API split.
Dependencies
Internal packages: TC.ConnectionBroker.* (tc-connectionbroker) for brokered SQL connections and TC.Exceptions.* (tc-exceptions) for exception logging. No third-party services.
Data stores
The shared Phenix SQL Server database (ConnectionBroker connection PhenixDatabaseLocal); all reads/writes go through Phenix feature stored procedures.
Integration points
WCF only (wsHttp and netTcp bindings). Consumers reference the published contract/client packages; there is no REST surface.
Code health
No test projects at all. README is a single line. YAML CI exists. Last commit 2025-11-21 — maintained but slow-moving. The client packages are analysed (NetAnalyzers, SourceLink) and better cared for than the service itself.
Modernisation risks
High: a WCF-only service on .NET Framework 4.7.2 with no tests, sitting in the critical path of many Phenix applications (high fan-in through TC.Phenix.Feature) and coupled to the shared Phenix database via stored procedures. Feature flagging is exactly the kind of capability that could migrate to a modern .NET 8 REST/gRPC service or an off-the-shelf flag platform, but every consumer's WCF client binding would need replacing.