-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feat]: Configure release notes #29
Comments
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? |
yes, it is correct :) |
This seems like a very interesting feature! Loved it. |
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 |
@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:
Here, the latest published deployment was
Now here, we need to take into consideration the rollbacks. What happens when a user rollbacks? Shall we notify as:
WDYT? Also, another question, this works as long as the user does not use |
@svedova Maybe we can just put the name of the branch into the release notes without collecting the deployment ID? |
@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 |
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. |
@ivanlori awesome, then perhaps we can leave this to the user. The
WDYT? |
@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. |
The goal
![Screenshot 2020-09-17 at 11 25 36](https://user-images.githubusercontent.com/7620920/93454206-f0849080-f8da-11ea-8343-e3da60623aed.png)
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
The text was updated successfully, but these errors were encountered: