Member Avatar for pritaeas

I'm currently looking into the automatic generation of release notes (or change log) when we create a new release. I'm wondering how any of you tackle this. So far I've found these four interesting options:

Any insights greatly appreciated.

  • 2 Contributors
  • 3 Replies
  • 179 Views
  • 1 Hour Discussion Span
  • Latest Post Latest Post by Ketsuekiame

Dani AI

Generated

Since this thread was started, the practical options have converged into three patterns: (A) use an off‑the‑shelf pipeline extension that formats work items/commits into a template, (B) call the Azure DevOps REST APIs from a pipeline/script and render a templated document, or (C) generate notes from a release webhook (serverless) or a commercial product that handles templating and distribution. ’s instinct to look for community tools is still sound; ’s caution about manual review is also sensible — automation should produce a curated draft, not always the final copy. ()

A reliable, repeatable pipeline pattern: 1) enforce linking discipline (require PRs/commits be linked to work items and enable automatic linking in pipeline settings), 2) decide the comparison window (tags, build IDs or releases), 3) call the REST endpoints that return associated work items/changes (for example, the build work‑items and “get work items between builds” APIs), 4) fetch full work‑item fields and render using a template (Markdown/Handlebars/HTML), and 5) publish the result (artifact, wiki page, release attachment, or email). The “automatically link” option and the build/work‑item APIs are the foundations for correct automation. (learn.microsoft.com)

If you want low effort, the marketplace extension route plugs into existing pipelines and supports templates and publishing; commercial products (templates, PDF/HTML styling, Teams/Email delivery) are available if you need polished output. For full control, a webhook+Function app can generate a file on release creation and store it in blob/wiki — Microsoft even provides a sample generator to illustrate this flow. Either way, keep a human review step: automated lists are excellent inputs but often miss the “release summary” narrative. (agileextensions.com)

Quick troubleshooting tips: missing WIs usually mean commits/PRs weren’t linked or the pipeline option to auto‑link wasn’t enabled; pipeline tasks that call REST APIs usually need the agent OAuth token or a PAT (enable “Allow scripts to access OAuth token” and test locally first). Test the whole flow on a staging branch, verify the exact build IDs you compare, and treat the generated notes as a draft to be reviewed before publishing. (github.com)

Short, practical takeaway: automate collection and templating, but enforce linking discipline and add a short human‑curated summary at the top. Automation saves time; governance and a quick editorial pass keep your notes useful.

Recommended Answers

All 3 Replies

Member Avatar for Ketsuekiame

We write our own (in a word document) as generally TFS can't be trusted :)

Edited by Ketsuekiame
Member Avatar for pritaeas

But I assume you write your own based on the list of associated work items and/or check-in comments?

Member Avatar for Ketsuekiame

I refuse to answer that question on the basis that the answer may serve to incriminate me ;)

EDIT: I'm afraid I'm going to be no help in this thread, so bowing out now before it derails :)

Edited by Ketsuekiame
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.