Platform Evolution
Assessment run-2026-07-27-1 · 213 of 213 repos assessed
Repos / job-commission-set-payable

job-commission-set-payable

Console job that triggers Phenix commission line status updates, marking commission payable either for all bookings at the present date or for a single specified booking.

57 · ambermediumloosely attachedOn-premZDD: needs workjob

Health score

57

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.


Runtime currency / 25
0
.NET Framework, out of mainstream support
Legacy transport / 15
6
Calls at least one legacy WCF endpoint
Test posture / 15
8
Some tests, coverage is thin
Security hygiene / 15
15
No credentials found in source
Dangerous coupling / 15
15
No dangerous coupling detected
Activity / 10
8
Last commit six to twelve months ago
Deployment hygiene / 5
5
CI in place
Health over time
2026-07-24 (run-2026-07-24-1): 572026-07-27 (run-2026-07-27-1): 57
No change since 2026-07-24 (57 to 57).

Facts

Languagescsharp
FrameworksTC.MaintainanceTools.SimpleJobs 6, TC.ConnectionBroker 1.19
Runtimes.NET Framework 4.7.2
Tests / CIsome / CI in place
Last commit2025-12-10
OwnerOwner unknown (mapping to be curated)
DomainPayments and finance (system generated; curate in repo-owners.json to override)
Product areaPhenix
HostedOn-prem Deployed to our own machines
  • Release "\finance\jobs\job-commission-set-payable Dev": QA: deployment-group phase (agents on our own machines)
  • Release "\finance\jobs\job-commission-set-payable Release": Staging: deployment-group phase (agents on our own machines)
  • Release "\finance\jobs\job-commission-set-payable Release": Staging: deployment-group phase (agents on our own machines)
  • Release "\finance\jobs\job-commission-set-payable Release": Production: deployment-group phase (agents on our own machines)
Releases2 release pipeline(s): \finance\jobs\job-commission-set-payable Dev; \finance\jobs\job-commission-set-payable Release
Integrationwcf
SourceOpen in Azure DevOps

Risk flags

Each flag links to its glossary definition.

Dependencies in context

No internal dependencies, dependents or shared stores recorded for this repo.
greenamberreddata store (square, dashed link)Node size follows fan-in. Click any node to open it.

Entanglement

loosely attached Bound into the core by 1 mechanism(s).

  • Speaks WCF (client)

Detaches when its WCF surface gains a modern interface or its WCF calls move to one.

Depends on / used by

Depends on (0)
Nothing internal.
Used by (0)
No internal dependents.

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 work

Feasible 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 runtime: the rolling drain works (stealth releases prove it) but relies on fix-forward risk rather than dual-version safety.

Dependencies and gotchas
  • Consumes WCF contract packages: never take a breaking client bump mid-feature, and treat obsolete warnings as migration debt
Steps
  1. Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
  2. Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
  3. 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.
  4. Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
  5. 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).
  6. 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 applicable

No SQL Server dependency is recorded for this repo. Nothing to migrate.

Containerisation

Feasible after replatforming

Appropriate, but the .NET Framework runtime has to go first; container work rides along with the replatform rather than preceding it.

Blockers
  • .NET Framework only runs on Windows; practical (Linux) containers need modern .NET
Steps
  1. Replatform to modern .NET first (see the recommended actions). Containerising then becomes routine.
  2. Add a Dockerfile and make the app read all configuration from environment variables and the secrets manager, never from machine-local files.
  3. Log to stdout and expose a health check endpoint so ECS can supervise it.
  4. 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.
  5. 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 job-commission-set-payable to modern .NET

Runs on .NET Framework 4.7.2, out of mainstream support. No pinning dependency blocks it; sequence by fan-in (providers before consumers).

Impact: Reduces the end-of-life runtime count

proposed

Assessment notes

job-commission-set-payable

Purpose

A thin scheduled console job (TC.MaintainanceTools.CommissionLineStatusUpdate) that calls the Phenix booking service to perform commission line status updates, i.e. set commission payable. It runs across all bookings at the current date by default, or a single booking when a BookingId setting is supplied.

Tech stack

  • C# console app targeting .NET Framework 4.7.2 (net472) with SDK-style csproj, modern LangVersion 14 and nullable enabled via Directory.Build.props, plus a broad analyser suite (Sonar, NetAnalyzers, SecurityCodeScan).
  • Uses the in-house TC.MaintainanceTools.SimpleJobs framework with web/app.config configuration, TC.ConnectionBroker.Wcf for environment-aware connectivity, TC.Phenix.Services.Client 8.0, TC.ContactCentre.ServiceClient, and SimpleInjector for DI.
  • Per-environment app.*.config XDT transforms (testqa, datafixqa, opsdev, liveproviderqa, preproduction, production).

Deployment

Prod application with 2 releases. Build pipeline job-commission-set-payable (classic-style build.yaml: VSBuild/VSTest on a Windows agent, XDT transform script, zip artifact) feeding release pipelines \finance\jobs\job-commission-set-payable Dev and \finance\jobs\job-commission-set-payable Release.

Dependencies

  • Internal NuGet packages: TC.Phenix.Services.Client, TC.ConnectionBroker.*, TC.MaintainanceTools.SimpleJobs.*, TC.ContactCentre.ServiceClient, TC.Exceptions.WebApiClient.
  • Git submodule deployment-scripts (build-time only; that repo is not in the deployed-repos inventory, so it is not listed as an internal dependency).
  • Third-party: SimpleInjector.

Data stores

None accessed directly; all commission updates happen inside Phenix via the booking service facade (PerformCommissionLineStatusUpdates).

Integration points

  • WCF calls to the Phenix booking service via TC.Phenix.Services.Client.BookingServiceReference over TC.ConnectionBroker.Wcf.

Code health

  • Small codebase with an MSTest test project (SetCommissionPayableTests) run in CI via VSTest.
  • CI is an older Windows-agent YAML pipeline (NuGet restore + VSBuild + XDT transforms) rather than the shared dotnet templates used by newer jobs.
  • Recently touched: last commit 2025-12-10.

Modernisation risks

  • Runs on .NET Framework 4.7.2, requiring Windows hosts and MSBuild/VSTest build agents; a candidate for the same .NET 8 migration already applied to sibling jobs such as job-close-bookings.
  • WCF client dependency on the Phenix booking service ties it to that legacy service surface.
  • Config management via XDT transforms and app.config bindingRedirects adds friction; otherwise logic is trivial and low risk.