Integration Hub

Keep a traceunified record and its twin in Jira or GitHub in step, link Bitbucket commits to the items they name, and see what every sync cycle did.

Integration Hub connects traceunified to the tools your engineers already work in. A requirement or test case can live as a governed record here and as an issue in Jira or GitHub, with the two kept in step continuously. Commits and pull requests in Bitbucket Cloud are linked to the items they name, so the code behind an item is on its record.

This release connects Jira and GitHub, which sync items in both directions, and Bitbucket Cloud, which links code and syncs nothing. A generic REST connector is built and is offered once it has run against a live instance of its tool.

Three objects, one integration

Everything in the Hub is built from three things, and each has its own screen:

  • A connection is how traceunified reaches the other tool: an address and a credential.
  • A collection is what you are talking about over there: which projects, which artifact type, and which traceunified item type those artifacts map onto.
  • An integration is what actually moves: it runs a collection on its own schedule, with its own rules for direction, filtering and collisions.

One connection can serve many collections, and one collection can be run by several integrations. traceunified is always one end of every integration.

Declared, not inferred

A sync that guesses is one somebody has to audit by hand. So every field declares which way it moves, every two-way field has a stated answer for an edit made on both sides at once, and every route names exactly which projects and item type it covers. An inbound edit lands through the same save path as a person’s, as a new version with an audit entry, attributed to the mapped individual. When nobody can be matched, the edit is held rather than attributed to someone plausible.

Polling guarantees it, webhooks make it quick

Change detection polls on its own interval, with a daily full scan behind it, so a missed delivery costs latency and never a change. Where the connection’s account can manage webhooks, the product registers its own and keeps it in repair, so edits arrive in seconds.

What’s in this section

Was this helpful?