After the merge

kanman stays with its work after the merge: release notes, watching the deploy, checking production through the story's acceptance check and your signals, and telling everyone when it is live or what failed.

A merged pull request is not the end of a story. kanman stays with its work until it is in production and tells everyone who waits for it, the way a good colleague closes the loop.

Set it up in the After merge card of Team > Checks and delivery (/<workspace>/teams/<team>/team/checks). Old links to the former After merge page land on that card. Every change saves at once: Saved shows next to it, and Undo brings the previous value back.

Team tab, Checks and delivery, After merge: release notes, the changelog path, the production environments to watch and closing the loop

Release notes

Right after the merge, kanman writes the story’s release note where your team wants it:

Setting What kanman does
In the pull or merge request description (default) Adds a Release notes section to the merged pull or merge request: the story key, its title and its acceptance criteria.
In the changelog file Proposes the entry in a small follow-up pull or merge request that changes only the changelog (CHANGELOG.md unless you name another file). kanman follows the file’s own format: in a Keep a Changelog file the entry goes under Unreleased, in Fixed, Added or Changed. Without a changelog kanman creates one. You review and merge the follow-up like any other change.
Off No release notes.

kanman also comments on the tracker issue that the story is merged and that it watches the deploy.

Watching the deploy

kanman watches the deployments of the story’s repository:

  • GitHub: deployments and their status, as GitHub reports them.
  • GitLab: environments and deployments, also on a GitLab behind a VPN, which kanman reads through your runner every few minutes.

A successful deployment to one of the team’s Production environments ships every story of the repository that was merged before it. Add the environments as chips; prod* matches every environment that starts with prod. The default is production, prod and live.

Checking production

kanman calls a story live only when it saw it work there:

  • The acceptance check: when the story has a live acceptance check (a UI or API check in its Demonstrate block), kanman runs it against the deployed environment.
  • Your signals: when an incident of the team opened since the merge and is still open, kanman says so instead of calling the story live. See Incidents and on-call.
What kanman saw What it says
The check passed in production, no incident open Live on production
The check fails in production Fails on production, with the result. kanman files a regression story right away.
An incident opened since the merge Deployed, incident open, naming the incident
No live check for the story Deployed, not checked: kanman says plainly that it cannot confirm the behaviour itself

When a check cannot run (for example while your runner is offline), kanman waits and tries again; it never guesses.

Closing the loop

Once kanman knows how the story stands in production, it tells everyone, once:

  • The tracker issue gets a comment, for example “PU-43 is live on production: its acceptance check passed there”. A live story stays in its Done status.
  • The story’s card in the team’s chat ends with the production step, so everyone who follows the story sees it without a new message.
  • Where the work started: the Slack thread the request came from, or the pull or merge request where someone mentioned kanman.

Turn this off with Tell everyone when it is live; kanman then only records the result on the story.

Last updated: January 1, 0001

Open kanman