tc-public-features
.NET 8 feature-flag API for the public/myTC customer estate, deciding per-customer feature enablement (percentage rollouts, per-Travel-Counsellor allowlists) with sticky decisions stored in MongoDB.
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 | ASP.NET Core 8, MediatR 12 |
| Runtimes | .NET 8 |
| Tests / CI | good / CI in place |
| Last commit | 2025-05-02 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Public web (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | AWS Deployed to AWS
|
| Releases | 0 release pipeline(s): |
| Integration | rest, jwt |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
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
No excuseNothing technical is holding this repo on the three-week release. It either already deploys without downtime (AWS) or is a modern, well-tested service the automated stealth path can carry today. Already deploys as a container to AWS, which releases without downtime today. Separating it from the three-week release is a process decision, not a technical one.
- 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.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Use ECS rolling deployments with health checks gating traffic, and take this service off the three-week release train.
- 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
Already containerisedIts pipelines already build containers and deploy to AWS. Nothing to do here.
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
tc-public-features
Purpose
Feature-flag service for the public website / myTC customer platform. GET /Features returns the features enabled for the authenticated customer; FeaturesConfiguration endpoints list and save flag definitions. A resolver pipeline (PercentageAllocationResolver for gradual rollouts, TravelCounsellorResolver for per-agent allowlists) decides enablement per customer, and MediatR CustomerFeatureDecided notifications persist the decision so customers get a sticky experience.
Tech stack
C# on .NET 8 throughout. ASP.NET Core Web API with two controllers, MediatR 12 for in-process eventing, MongoDB.Driver via TC.ConnectionBroker.Mongo (target PublicFeatures), TC.ScriptRunner.Mongo migrations (five numbered scripts run at startup), TC.Public.Jwt.Auth for myTC user authentication/middleware, Swashbuckle (dev only), TC.Diagnostics and MongoDB health checks.
Deployment
Included as prod_application with 0 releases — AWS/YAML only. Build pipeline tc-public-features from in-repo azure-pipeline.yaml using the shared InternalOSS/azure-pipelines-templates jobs/ci.yml (SDK 8.x, test selection **/*.Tests.csproj): container built after build (containerNamespace: cx-public), deployed to ECS via the aws-public-tc-apps Terraform repo with tfvars, eu-west-1, functional area public.
Dependencies
Internal: TC.ConnectionBroker.Mongo/Extensions.DependencyInjection (tc-connectionbroker) and TC.Diagnostics.HealthChecks (tc-diagnostics-portal). TC.Public.Jwt.Auth and TC.ScriptRunner.Mongo are internal packages whose source repos are not confirmed in the included list. No external third-party services.
Data stores
Owns the PublicFeatures MongoDB database (feature configurations, customers, customer-feature lookups and data-linkage collections), resolved through the Mongo connection broker; startup migrations manage indexes and seeded flags such as InspirationalContent.
Integration points
Inbound REST secured with myTC JWT auth (the config controller notably has no explicit authorisation attribute beyond the shared middleware). No outbound service calls, message bus or streams — eventing is in-process MediatR only.
Code health
Good: four test projects — unit tests over the resolvers/checker/loader/eventing plus two integration suites using Testcontainers.MongoDb, with shared fixtures and coverlet. No README at all, though. Last commit 2025-05-02, so quiet for over a year but not abandoned.
Modernisation risks
Low. Modern .NET 8, containerised ECS deployment, real tests including Mongo integration coverage. Watch items: the feature-configuration write endpoint's authorisation is only as strong as the shared JWT middleware, the estate now has at least two feature-flag systems (this and tc-features / phenix-feature-service) covering different audiences, and the missing README leaves resolver semantics undocumented.