Change Set Release Note (Variant 1)

This variant of the release note generates a release note when code has been merged between branches. A typical branch strategy is the Development and Release Isolation strategy.

The problem this feature solves is that when all features and bugs in the development phase have been implemented or corrected and merged to the main branch, a branch is taken out for the release.

Since the release function in TFVC only shows the work items that have been checked in between releases on the release branch, the release branch that is created will not be able to show which work items it contains because the change set lies on the main branch.

Therefore, the function fetches the change sets that have been merged from dev to main in this case.

This means that a release note can be published as soon as the release branch is created. If a further release needs to be created from the release branch due to bugs being found, the "DevOps Release Note" function is used since DevOps keeps track of which work items have been checked in since the previous release.

On the right side of the grid there is a button menu with the following functions.

This function compares the change sets that has been checked in to the ‘from’ branch and merged to the ‘to’ branch. The from date should be the date after the current release branch was created. The to date is optional, if not set it will find all the change sets until now.

The process will add the release name to the Tag of the related work items and update any custom field that has been defined as a release field (this is optional). The update will first verify the changes and the commit the changes. After this step the release note will be created.

This release note is created entirely using MD language, it will be based on the change sets, therefore if many check-ins have been done, the work item will be repeated. To get a shorter list, it is best practice to only check in the code to the development branch when smoke test has been performed in the developer environment on the development branch. The list will be a 1:1 list based on the current grid. If that is the case that there have been multiple check-ins for a work item, use the query based report instead of this variant.

The query-based release note uses a query to list all the work items included in the release note. This is the preferred way of creating a release note as it results in a clear report. The report is also created with the Markdown language, but no list is created, instead queries is created for the work items, it is possible to use 2 variants of queries, one for bugs and one for PBI/User stories, it's all controlled by the WIQL editor.

The updates are the same as for a MD based report, the Tags in the work items is updated with the release number, and if a custom field is set to get the branch information, that is also updated. This is all controlled by the application settings.