Promotion rules and deploy gates
Say what must wait for what before code moves to the next environment, and let your CI ask SeamTrail before it deploys.
SeamTrail can answer one question for your CI: "May this go to this environment?"
It answers from what it already knows: which tickets wait on which, how far each ticket's code has gone, and your checklists.
Where code is
SeamTrail tracks how far each ticket's code has gone:
| Step | How SeamTrail knows |
|---|---|
| Merged to dev | A pull request that names the ticket is merged into the default branch. |
| On stage | Your CI reports a deploy to stage that contains that merge. |
| In prod | Your CI reports a deploy to prod that contains that merge. |
A ticket never moves backwards.
Report deploys from your CI
- Open your org's Settings → Tools → Deploy webhook and click Create key. Copy the key now. It is shown only once.
- Copy the ready-made line from that page into your CI, after each deploy.
The line sends four things: the repo (owner/name), the environment (dev, stage or prod), the commit, and success or failure. Sending the same deploy twice is safe.
Creating a new key stops the old one at once.
Promotion rules
Promotion rules are extra deploy rules on top of Jira's own "blocked by" links. Each feature has its own.
Dependencies. Make one thing wait for another:
- Ticket → ticket: PAY-7 waits for PAY-4.
- Team → team: the Frontend team waits for the Backend team.
- Strict: wait until every upstream ticket reaches each environment.
- Loose: wait only for the tickets it really depends on.
Each dependency either blocks the deploy or only warns.
Checklist. Steps to tick before each environment, like "feature flag configured". A step can cover the whole feature, one team or one ticket. It is needed from a chosen environment upward.
Each environment is ticked separately. Done for dev does not count for stage.
Add a rule
On the feature, click + Add memory and pick Dependency or Checklist. You can also ask the SeamTrail agent or your AI assistant.
Adding and changing rules needs the feature's Admin or Manager role.
The deploy gate
Before a deploy, your CI asks SeamTrail. SeamTrail answers allow or block, with the reasons.
It blocks when:
- a ticket waits for another ticket that has not reached this environment yet, or
- a checklist step is not ticked for this environment.
A blocker that Jira says is Done, but whose code SeamTrail never saw, does not block. It becomes a warning: make sure its code is out.
Set how strict, per repo
Open your org's Settings → Tools → Deploy rules. For each repo, pick:
| Mode | What happens |
|---|---|
| off | Never blocks. The answer still lists what is not ready. |
| warn only | Never blocks. Reports what is not ready. |
| block | Stops the deploy until it is ready. |
Every repo starts at off. Org Admins and Managers change it. Repos appear on this page once SeamTrail sees a deploy or a merged pull request.
Add the gate to your CI
Copy the snippet from your org's Settings → Tools → Deploy rules. It has the right address. It looks like this:
allow=$(curl -s "<gate address from SeamTrail>" \
-H "Authorization: Bearer <your deploy key>" -H "content-type: application/json" \
-d '{"repo":"owner/name","env":"stage","commit_sha":"'$COMMIT_SHA'"}' | jq -r .allow)
[ "$allow" = "true" ] || { echo "SeamTrail blocked this deploy"; exit 1; }It works in any CI: GitHub Actions, Bitbucket Pipelines, Jenkins and others. You can also send a ticket key (ticket) or a branch name (ref).
The gate is a guard rail, not a lock
Your pipeline asks and obeys. Someone who can edit the pipeline can remove the check. For a hard lock, use your code host's branch protection or environment protection rules.
PR check (GitHub)
Turn on PR check for a repo in your org's Settings → Tools → Deploy rules. It is off until you turn it on.
SeamTrail then keeps one comment on each pull request in that repo, only when a ticket it names is not ready. It updates the comment as things change, and turns it into "all clear" once they are fixed.
The comment uses rule facts only: ticket keys, what they wait for and checklist steps. It never quotes your chats.
Coming soon
- A required status check on pull requests, so your branch protection can block the merge.