Releases you don’t plan in a spreadsheet.

Group cards per version, let the test run say whether it can ship, and see which cards went live after the deploy. The numbers on how fast you ship come along by themselves.

From backlog to production.

1. Plan the version: Put cards in a release and follow how much is done.
2. Test it: A test run takes your test cases along. What fails becomes a card, and releasing asks for confirmation first.
3. Ship it: When your pipeline reports the deploy, the release is marked as shipped and every card knows it is live.

Know it can ship, before it ships.

Test cases per section, and per run what passed, failed, is blocked or still to do. A failure gets a note and a card, and as long as the run hasn’t passed, the release asks for confirmation.

DORA metrics without a spreadsheet.

Deploy frequency, lead time, deploys followed by an incident and time to restore, from the deploys, pull requests and incidents devbord already knows. Per project, per week, and next to the period before.

What comes with releases.

• Release board. Versions with their cards and progress. What doesn’t make it rolls over to the next one.
• Test runs. Test cases per section, and per run passed, failed, blocked or skipped, with a note.
• Deploy tracking. A secret URL for your pipeline, or GitHub and GitLab report it themselves.
• Changelog from the release. A release writes a draft for your public changelog.
• Errors per version. Crash-free sessions and the issues of that version, from error tracking.
• Delivery (DORA). Deploy frequency, lead time from commit to production, deploys followed by an incident and time to restore, each next to the period before.
• Review queue. The pull requests waiting for your review and the state of your own, with CI next to them.
• Decision log. What was decided, why, and what it replaces, linked to the cards that carry it out.

Frequently asked questions

Where do the delivery metrics come from?

From what devbord already tracks: deploys, commits and pull requests from the linked repository, and incidents. Nothing to fill in separately.

Does it work without GitHub?

Yes. GitLab and Forgejo/Gitea work too, and you report a deploy with one request to a secret URL, from any pipeline.

Can a release ship while tests fail?

A release with a test run that hasn’t passed asks for confirmation before it ships. It stays your call.

Which plan includes release management?

Release management is part of Premium. That is one fixed price per workspace, however many members you have.

Changelog · Error tracking · Sprints, roadmap and goals

devbord · Pricing: one flat price per team · News · API documentation · Support: help and contact · Privacy: what we can and cannot see · Terms of service · Privacy policy · Error tracking for dev teams, Sentry-compatible · Time tracking and invoicing for dev teams · Status pages with uptime monitoring and incidents · Changelog and release notes from done cards · Incident management and on-call for dev teams · Meeting agendas, async stand-ups and retros for dev teams · A feedback portal with voting and a public roadmap · Automation, a REST API, webhooks and an MCP server for dev teams · Sprint planning with burndown, a roadmap and OKRs · A Trello alternative for dev teams · A Sentry alternative that keeps your SDKs · A Linear alternative with error and time tracking · A Jira alternative for small dev teams · An Asana alternative for software teams · A ClickUp alternative with error tracking and invoicing · A Toggl alternative with a board and invoicing · A Harvest alternative with a kanban board · A Statuspage alternative with monitoring built in