ttand-database
Change-script database project for the TTAND (The Travel Agent Next Door) SQL database holding profile, address, passenger, branch and client data consumed by the Phenix contact API.
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 | - |
| Runtimes | - |
| Tests / CI | none / CI in place |
| Last commit | 2026-05-18 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Contact centre and CRM (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | On-prem Deployed to our own machines
|
| Releases | 1 release pipeline(s): ttand-database |
| Integration | sqlserver |
| 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
Not applicableNot a deployed service (libraries, database definitions, desktop apps) or a retirement candidate not worth the investment. Schema repo: changes ride with the owning services under the expand and contract pattern.
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
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
ttand-database
Purpose
Database-only repo for the TTAND brand (The Travel Agent Next Door, TC's Canadian host-agency brand). Three numbered change scripts create the schema — Profiles, Addresses, PassengerDetails, ClientDetailsClone and Branches tables (branch records carry fiscal/VAT/invoice-numbering columns from the source agency system) — and grant a contactApi_service role SELECT on dbo for the contactApi login.
Tech stack
Plain T-SQL change scripts in a netstandard2.0 stub Ttand.csproj (dbdeploy-style Change folder, same pattern as other estate DB repos). No application code.
Deployment
prod_application, release_count 1. YAML build.yml uses the shared db-differential-package.yml template to build a differential package for the Ttand database; build and release pipelines are both named ttand-database. The README states these scripts create/update the schema for the TestQA environment only — preproduction and production use an already-existing database.
Dependencies
None internal or external; it is a schema definition. Downstream, phenix-contact-api's TtandDbContext/Ttand DAL reads this database, and the mail-template service renders TTAND-branded emails from data sourced through that API.
Data stores
Defines the Ttand SQL Server database itself.
Integration points
SQL Server only — consumers connect directly (the scripts provision read-only access for the contact API's login).
Code health
Active enough (initial creation plus permissions scripts, last commit 2026-05-18). No tests, which is normal for estate DB repos. README is one honest sentence.
Modernisation risks
Low as a repo, but the model is fragile: the scripts are only authoritative for TestQA while production runs a pre-existing database, so schema drift between environments cannot be detected from source. Table shapes cloned from the source agency system (ClientDetailsClone) suggest an interim migration structure that should eventually fold into the contact-centre data model.