CODEWITHSUNDEEP
azure-devopscontinuous-integrationsemantic-versioningcontinuous-deliveryconventional-commits
David Coxsey
David Coxsey

Reputation: 105

When should you update release notes/changelogs?

Looking to automate our changelogs and release notes with conventional commits and Azure DevOps pipelines, and the process seems "simple" based on all of the documentation and videos I've consumed over the past few weeks. However, everything I've ran across shows teams making updates to their changelogs and/or release notes when PRs are approved and the CI process is finished, which seems like the right way to do it.

However, are there instances where these changelog or release notes generation doesn't happen until the changes in question have been sent to production?

Upvotes: 2

Views: 1146

Answers (1)

jwdonahue
jwdonahue

Reputation: 6669

Maintaining a changelog in the repo does not scale well. In a multi-developer environment you will slow everybody down trying to resolve merge conflicts. For a small enough team, manually editing and committing the changelog for every change is doable, but I'd recommend moving away from that practice.

Automated changelog generation from commit messages/Id's, including work-item id's and titles, just prior to package generation is a very good approach. These changelogs do not need to be checked-in to revision control. You should preserve past changelogs in an immutable form somewhere outside of the source repo.

At the very least, a changelog should include commit hash Id's for all changes and the Id from which the release was built. Adding work item Id's and titles is even more useful.

Build meta in the version string is a good place to encode a reference to the changelog, if your package feeds/tools preserve that field (some do not).

I would recommend maintaining a separate database of references to build logs (age these out), builds (keep these) and the associated commit hash from which they were built and reference to the associated changelog. Such a system allows you to scale up, without hinderance, to parallel and distributed builds running across any set of branches being worked at any given time.

Upvotes: 1

Related Questions