User Tools
userguidesanddocumentation:creatingreleasenotes
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| userguidesanddocumentation:creatingreleasenotes [2021/01/05 15:29] – 10.91.120.28 | userguidesanddocumentation:creatingreleasenotes [2021/06/25 10:09] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== Creating Release Notes ====== | ||
| + | ===== Release Notes - Background ===== | ||
| + | |||
| + | Release notes are created to accompany each development sprint. They denote the tickets worked on as part of each sprint and include a concise description of the general updates made. | ||
| + | |||
| + | Each customer will receive their own version of the release notes including their customer specific tickets as well as general Errigal items. | ||
| + | |||
| + | Release notes are deployed to the Support Page during a release. More information on the Support Page can be found on the [[development: | ||
| + | |||
| + | ---- | ||
| + | |||
| + | ===== Release Notes Creation Process ===== | ||
| + | |||
| + | ==== Pre-work: ==== | ||
| + | |||
| + | * Make note of all Release Notes Tickets - Jira Filter | ||
| + | |||
| + | ==== Sheet Setup: ==== | ||
| + | |||
| + | * Export a list of tickets from Jira from the current sprint - e.g. Sprint: 3.13, Fix Version: 3.13 | ||
| + | * Fields: Issue Type, Issue Key, Description/ | ||
| + | * Add into a new Google Sheet in the Sprint Management > IDMS <current sprint> > Customer Release Notes - called IDMS <current sprint> Release Notes List | ||
| + | |||
| + | ==== Tickets List: ==== | ||
| + | |||
| + | * Once data is all on this sheet sort by Issue type | ||
| + | * Remove the following: Management, Release_Management, | ||
| + | * Review Operational tickets to see if they need to be included | ||
| + | * Remove Backlog Grooming related tickets | ||
| + | * Remove analytics / google analytics related tickets | ||
| + | * Sanity check for data integrity items i.e. adding or removing fields from DBs - these are important from a customer perspective so shouldn' | ||
| + | * Sanity check Scotty Pro related tickets to see if related to the Ticketer specifically or just ScottyPro | ||
| + | * Tickets that involve logging or similar tasks normally can be removed (not relevant to the customer) | ||
| + | * Remove tickets that involve deprecated code cleanup and analysis | ||
| + | |||
| + | ==== Sort Tickets By Status: ==== | ||
| + | |||
| + | * Remove Closed Tickets | ||
| + | * Review Open Tickets to see if they are to be included or are being pushed to the next sprint | ||
| + | * Review resolved tickets to see if they are to be included (some may be analytical tickets that aren't needed in release notes) | ||
| + | |||
| + | ==== Fill in Customer (WRT Rel Notes) column: | ||
| + | |||
| + | * If a ticket has the Platform_Wide label the customer is ALL | ||
| + | * If Security Level is AT and no Platform_Wide label the customer is ATC | ||
| + | * If Security Level is EXT and no Platform_Wide label the customer is EXT | ||
| + | * If Customer is not apparent, consult with the developer to verify | ||
| + | |||
| + | ==== Fill in Application and Project columns: ==== | ||
| + | |||
| + | * Can be discerned from ticket summary | ||
| + | * Used for logical grouping of features for release notes and flyer | ||
| + | * Projects will normally have the same **Customer (WRT Rel Notes)** so do another pass on this column | ||
| + | * General tickets that don't relate to a bigger project can be classed as **General Fixes** | ||
| + | * Stand alone tickets with **Issue Type = Bug** can have **Project = Bug Fixes** | ||
| + | |||
| + | ==== Fill in Include In Release Notes column: ==== | ||
| + | |||
| + | * Any tickets that have Application, | ||
| + | |||
| + | ==== Tidy Up: ==== | ||
| + | |||
| + | * Highlight any outstanding items: Blank Application, | ||
| + | * Consult with developer or test team to determine the solution | ||
| + | * Some open tickets may be pushed out to next sprint | ||
| + | * Some resolved tickets may be analytical and therefore not needed | ||
| + | * Some tickets may be missing the correct label to determine the customer or project | ||
| + | |||
| + | ==== Release Notes Generation: ==== | ||
| + | |||
| + | * Pull the latest version of the [[https:// | ||
| + | * Create copies of existing release notes files per customer and update them accordingly to match the current sprint. (ATC, EXT, SCO, KLA) | ||
| + | * Include the tickets relevant to each customer specifically and Errigal related items. | ||
| + | * Include appropriate descriptions of the updates made as part of the sprint | ||
| + | * Once finished and proofread, generate the PDF versions and add to the Sprint Management > Release Notes folder for the appropriate sprint. | ||
| + | * Once this is done, let Sophie know they are ready so she can use them for the relevant test plans. She will advise if there are any further updates to be made. | ||
| + | |||
| + | ---- | ||
| + | |||
| + | ==== Release Notes Deployment: ==== | ||
| + | |||
| + | * The deployment of release notes is done during the sprint release process. | ||
| + | * This process is automated via a Jenkins project. | ||
| + | * For more detail on this process see the **Deploy the user guide update to the Support Page** section of the [[userguidesanddocumentation: | ||
Page Tools
