Changelog and release notes for Azure DevOps

Most teams ship steadily and tell their customers almost nothing. Not out of secrecy — writing a changelog means trawling through tickets after the fact, working out which ones actually reached production, and translating them from internal shorthand into something a customer would understand. It is nobody's job, so it slips.

BranchDeploy already records every deployment you make from an Azure Boards work item: which ticket, which branch, which environment, and when. That record is the raw material for a changelog. Release notes turn it into one.

How it works

1. Open Release notes in your BranchDeploy account. Your recent deployments are listed, newest first.
2. Add the ones your customers would care about. Each becomes an item, pre-filled with the work item's title and categorised from its type — a Bug becomes a fix, a Feature becomes a new feature.
3. Rewrite each item for customers. The ticket title is a starting point, not publishable copy.
4. Press Publish. Nothing is visible to anyone until you do.

Deployments you have already written up drop off the list, so you cannot announce the same change twice, and nothing is missed between releases.

Two ways to publish

A JSON feed your app reads

Every feed has a read-only JSON endpoint that needs no authentication and no API key. Fetch it from your own application and render a "What's new" panel that matches your product, with your own design and your own wording:

GET https://api.branch-deploy.dev/api/public/release-notes/<feed-id>

The response carries the entries, their items, and a top-level updatedAt so you can tell whether anything changed since you last fetched. Responses are cached and support ETag, so polling it costs you very little.

A page we host

If you would rather not build anything, publish to a page we host and share the link. Add your logo, brand colour and homepage URL and it becomes yours; leave them blank and it falls back to BranchDeploy branding with your feed's title. The page is server-rendered with no JavaScript at all, so it loads instantly and works everywhere.

What never gets published

A changelog is customer-facing, so the public output deliberately contains none of your internal detail. It carries the wording you wrote and nothing else — no work item IDs, no branch names, no pipeline names or run numbers, no environment names, no organisation or project identifiers, and no names or email addresses of the people who deployed.

The identifier in your feed URL is random. It is not derived from your Azure DevOps organisation or project name, so the URL gives nothing away either.

Drafting with an AI assistant

If you have connected ChatGPT, Claude or another MCP client, you can ask it to draft release notes from what shipped. It reads your deployments, writes customer-facing copy, and saves a draft for you to review. Publishing always requires your explicit confirmation against a preview of the exact content.

An owner or admin can also allow the assistant to read the description on the work item behind each deployment, which produces far better copy than titles alone. That setting is off until you turn it on, and it is limited to work items BranchDeploy has already recorded a deployment for.

URLs that do not change

Once you have shared a feed URL, it is baked into your application and into your customers' bookmarks. Both the JSON endpoint and the hosted page keep the same address for the life of the feed. Renaming the feed, changing your branding, publishing, archiving and deleting entries all leave the URLs untouched.

Who can use it

Release notes are a BranchDeploy Pro feature. A feed is created automatically for each project you sync, so there is nothing to set up before you write your first entry. Owners and admins can write, publish and archive; viewers can read.

See the release notes documentation for the full JSON schema, pagination, caching behaviour, and worked integration examples.