Changes Set Release Note (Main only strategy)

If you are using a main only strategy there is no code merge to consider for the release note. All you must do is to keep track of the change sets created since the last release branch was created. The list has some more features compared to the list based on code merged between branches, it will show warnings if you have work items not ready to be included in a release branch. You can access the work items from the list and inspect them in detail.

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

Select the branch that you want to analyze the change sets for, take care and address the warnings as it indicates that you are not feature complete and risk to create a release branch with problems.

This function will verify all the work items referred to in a change set, use this function when you have made changes to a work item. The changes in state will be reflected in the list. The rule for what to verify is setup in the application settings.

The view warnings dialog shows all warnings for a selected change set, that is warnings for related work items in a change set.

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, its 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.