Map customers to their version
Your customers don’t all run the same code. When you tell Tracewell where your helpdesk keeps each customer’s version, plan and feature flags, every investigation analyses the commit the customer runs, with their configuration. You set this up once per helpdesk.
What to tell Tracewell
Section titled “What to tell Tracewell”Send Tracewell the following for your helpdesk. Only the repository is required.
| Setting | What it is | Example |
|---|---|---|
| Repository | The connected repository that holds the code your customers run | acme/app |
| Version field | The field that holds the customer’s version, and where it is: on the ticket, the organization or the requester. You can name more than one; Tracewell takes the first one that has a value. | Ticket field Product version, then organization field version |
| Tag pattern | How a version’s git tag is named, with {version} where the version goes |
v{version} or release-{version} |
| Plan field | The field that holds the customer’s plan, and where it is | Organization field plan |
| Flag field | A field that lists the customer’s feature flags that are on, such as a multi-select or a comma-separated text field | Organization field features |
| Where plans and flags are defined | A short hint to where your code defines plans and feature flags | config/plans.yaml |
In Zendesk, name a ticket field by its title, and an organization or user field by its field key.
Which commit an investigation analyses
Section titled “Which commit an investigation analyses”Tracewell reads the version from the ticket and puts it into the tag pattern: version 2.3 with the
pattern v{version} is the tag v2.3. The investigation analyses the commit that tag points at.
If Tracewell can’t find the customer’s version, it analyses your repository’s default branch instead, such
as main, and records why:
- No version: none of the version fields has a value for this ticket.
- No matching tag: your repository has no tag for the version, for example a typo in the field or a release that was never tagged.
Without a version field, every investigation analyses the default branch.
Tracewell compares the customer’s version with your default branch to find out whether a later change already fixed the problem, and names that commit and the release that shipped it. On the default branch there’s nothing newer to compare with, so the verdict can’t be Already fixed.
If you don’t set it up
Section titled “If you don’t set it up”If your workspace has one connected repository, investigations analyse its default branch, without a version, plan or feature flags, and record that no mapping is set. If it has several repositories, or none, Tracewell can’t tell which code to read: investigations stop right away, and the Tracewell app in the ticket asks the agent to have an admin check the code mapping.
The same happens when the repository in your mapping is disconnected. Connect it again, or tell Tracewell another repository.
Plans and feature flags
Section titled “Plans and feature flags”Tracewell takes the plan from the first plan field that has a value, and the feature flags from all flag fields. Each investigation records them together with the commit it analyses. Feature flag services such as LaunchDarkly aren’t read.
Check the setup
Section titled “Check the setup”Tell Tracewell a ticket to test with. Tracewell reads it and tells you the version, commit, plan and feature flags it resolves to, and whether it fell back to the default branch.