phenix-database
Change-script repository for the core shared Phenix SQL Server database, delivering schema changes, feature-flag toggles and provider configuration via the differential-package pipeline.
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 | sql |
| Frameworks | TC db-differential-package pipeline templates |
| Runtimes | SQL Server |
| Tests / CI | none / CI in place |
| Last commit | 2026-07-22 |
| 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): \finance\phenix\phenix-database CI |
| Integration | sqlserver |
| 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).
- Shares core database sqlserver:Phenix
Detaches when the shared database group it belongs to gains an owned API or completes schema separation (sqlserver:Phenix).
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 chance (frozen core)The deliberately frozen legacy core. Policy, not tooling: minimal change flows through these systems, on a slow scheduled cadence with coordinated maintenance windows. Named in the two-speed strategy as frozen legacy core: protect the core, release the rest. Changes here go through the slow scheduled cadence and coordinated maintenance windows.
- 2 system(s) depend on this repo; during a rolling deploy they will talk to old and new versions at once, so responses must stay compatible
- Shares sqlserver:Phenix with 21 system(s): destructive schema change is prohibited in a single release; expand and contract only
SQL Server exit
Owned at estate levelThis repo is a database definition, not a service. Its future is decided by the stage 4 database-as-product work for the systems that share it, not by a service-level migration.
Containerisation
Not applicableDatabase definition repos deploy schema, not a service.
Recommended actions
Rotate the credentials committed to phenix-database
Risk flags indicate credentials or keys in source (secrets-in-source). Rotate now and enable secret scanning in CI; this is independent of all other work.
Impact: Closes a live security exposure at near-zero cost
proposedAssessment notes
phenix-database
Purpose
Source control for changes to the Phenix database — the core operational SQL Server database behind the Phenix platform. Around 890 SQL files: a small Create folder (22 idempotent scripts, views and stored procedures only), an active numbered Change folder (~420 scripts) and a large Archive of applied changes going back years. Many changes are business configuration rather than schema: enabling feature flags (Is...Enabled toggles), setting up providers and updating supplier logins.
Tech stack
Pure T-SQL with a stub netstandard2.0 csproj to drive packaging. build.yml uses the shared db-differential-package pipeline template (same mechanism as the other TC database repos), producing differential deployment artifacts for the Phenix database.
Deployment
prod_application with 1 release. Build pipeline phenix-database CI from the in-repo YAML; release pipeline \finance\phenix\phenix-database CI. Very active — last commit 2026-07-22, with change scripts merged continuously (recent examples are feature-flag additions referencing work items).
Dependencies
No internal package dependencies — this repo is upstream of much of the estate rather than downstream of anything. At least five other assessed repos declare sqlserver:Phenix as a data store, and change scripts routinely touch provider/company-login tables consumed by Phenix booking and quote services.
Data stores
sqlserver:Phenix — the database this repo changes. Note that only views and stored procedures exist under Create; table DDL lives solely as historical change scripts, so the full current schema is not reconstructible from this repo alone.
Integration points
Direct SQL Server access by the many Phenix applications and services that share the database.
Code health
No tests or validation beyond the differential packaging. Several change scripts embed live provider credentials — supplier API keys, URLs and logins inserted into ProviderCompanyLogin (some password values are MD5 hashes, others are raw API keys) — so secrets are in source and in git history. Naming of change scripts is inconsistent but traceable to work items.
Modernisation risks
High: this is the shared-database heart of the legacy platform — every schema or config change here can affect multiple applications, and the coupling it represents is the main obstacle to decomposing Phenix. The credential-bearing change scripts should move to a secret store/runtime configuration, and adopting a full declarative schema (SSDT/state-based) would make the repo an actual source of truth instead of a change ledger.