[feat]: Configure release notes

[ivanlori]

The goal to have a page where the user can configure his release notes. During the configuration the user can add a title, a free field description or a default description with a multiple selection of suggested branches merged into the master one. Then there will be toggle boxes where the user can decide if that release should be published on slack, github, JIRA and other services with its own specific integration. For i.e. with slack the user has to specify the release channel used. In addition, there will be a simple text field where it is possible to put the recipient email in which the notes will be sent to. Where How it should be Mockup -> https://wireframe.cc/J8FIf5

[svedova]

Oh wow, I get it now. So the idea behind this issue is to use Stormkit as a tool to configure release notes and then whenever a deployment is published we send the release notes to the connected services. Am I understanding this correct?

[ivanlori]

yes, it is correct :)

[svedova]

This seems like a very interesting feature! Loved it.

[aerophobic]

awesome suggestion! really like the idea to automate the process of generating release notes in a smart way - maybe it could be even possible to pull information from related tickets (jira) or issues (github) to integrate into the release notes before publishing them to the connected services

[svedova]

@ivanlori, @aerophobic any idea how can we grab the notes to release? I have an idea in mind:

For each deployment we collect the commit sha that triggered that deployment. When a new deployment is published, we can calculate the latest deployment id that is published, get all the deployments in between, and write their commit messages as a release note.

So here's an illustration. Imagine we have these deployments:

Deployment ID	publish status	commit message
#4	new publish	Filter deployments
#3	was never published	Improve performance
#2	was never published	Fix autocomplete
#1	last published	some commit message

Here, the latest published deployment was #1. The user goes ahead and publishes #4. In this case the release note will be:

Released new version (this message can be configured from the UI and is a static one)

(the followings are collected dynamically)

- `#613411` Filter deployments
- `#154634` Improve performance
- `#535112` Fix autocomplete

Now here, we need to take into consideration the rollbacks. What happens when a user rollbacks? Shall we notify as:

Released rollbacked. Removed following features:

- `#613411` Filter deployments
- `#154634` Improve performance
- `#535112` Fix autocomplete

WDYT?

Also, another question, this works as long as the user does not use merge commits. Otherwise it will always be, merged xyz branch into master. Even worse case, if the user has a staging environment and uses merge commits, it will always be merged staging into master. Is there a workaround for this other than forcing to use rebase instead of merge commits?

[ivanlori]

@svedova Maybe we can just put the name of the branch into the release notes without collecting the deployment ID? Usually the workflow is for i.e.: I clone a branch from the master to work on a new feature, when the feature is completed it will be merged into master and in that case we put just the name of the feature branch on release notes. WDYT?

[svedova]

@ivanlori apologies maybe my post was a bit confusing. I didn't mean to include the deployment ID in the release note. It was just a way to understand which branches to include in the release notes.

I guess first we need to clarify the term release. Do we consider a merge to master|main a release, or a deployment being published to production?

[ivanlori]

Well personally I consider a merge into the master|main as a release in production, but it depends on the workflow of different teams of course. For i.e. I use a pipeline that automatically releases my code in production on every merge/commit on master but there should be the case in which the merge/commit is manually approved and released.

[svedova]

@ivanlori awesome, then perhaps we can leave this to the user. The Configure Release Notes screen may have an input where they can decide:

• Whether to trigger the release notes on merge to master or when a deployment is published.
• Whether to include the branch name in the release note or the commit message

WDYT?

[ivanlori]

@svedova yes it could be great with the possibility to choose. Consider also that the initial idea was with a free description field as well, so maybe this is the third case besides the automatic options.