Vega. Bug Fix and Hot Fix release process
Status | Indicator | Who | Action |
---|---|---|---|
Awaiting release | Indicates the item needs a bugfix/hotfix release to be created | PO | Confirmed an issue in folio-snapshot |
Awaiting deployment | Indicates release containing bug fix is ready to deploy to an environment | Lead Maintainer | Creates a module patch release from one or more PR |
In bugfix review | Indicates the bug fix has been deployed and is ready to test | Release Coordinator QA Lead | Requests and verifies deployment of a module patch release to Bug Fest |
Closed | PO or tester | Verifies fix |
Hotfix release process
Hotfix = a fix release that happens after the final flower release, and heads straight to production.
- Hotfix release = one that must be added to a release after the final release has been made.
- According to the release procedure hotfix release is not created except for P1 functional and P2 security issues. Once a hotfix release has been scheduled, lower priority issues (e.g. P2 and P3 functional issues) may also be included with permission.
- Set Release field of the bug Jira issues to <Number> and make sure the developers doing the fix know that it is needed for a hotfix.
- Get the issue fixed and test on https://folio-snapshot.dev.folio.org/
- Any hot fix issue should be approved:
- PO: Once the fix has passed testing in snapshot, post the Jira and seek approval for a hotfix release on the Slack #release_bug_triage channel. Please tag the approvers with your request (can be considered approved if you get the thumbs up from at least two technical approvers).
- If approved, ask the module maintainer to create a hotfix release and set the JIRA status to Awaiting release.
- You can get the module maintainer’s name from the Team Module Responsibility Matrix.
- The release needs to go to the appropriate Release branch and the Main branch.
- The release Jira should be linked to the appropriate epic.
- When the release is made, the module maintainer will announce it on the Slack #releases channel.
- When the release is made, the module maintainer will announce it on the Slack #releases channel and change the JIRA status to Awaiting deployment.
a. here is no need for the PO or module maintainer to request that the release be deployed
b. Jenkins robot automatically generate pull request for the branch of Platform Complete repository in Github for every released module if version incremented by "patch" number. (For example from 1.1.1 to 1.1.2)
c. Manual intervention required if release version requires change of major ( ex.1.1.1 to 2.0.0) or minor (ex 1.1.1 to 1.2.0) number. In this case PO or Dev lead have to notify DevOps and Anton Emelianov (Deactivated) about this change.
d. Folio hosting team checks for updates of Platform Complete one time per day and updates Bug Fest system with modules that have been released since yesterday's update.
e. Folio hosting team will post notification in #bug-fest Slack channel when update starts and ends.
8. Once daily update has been deployed to Bug Fest, Anton Emelianov will change the bug issue's status to In bugfix review which is the PO's trigger to do the final round of testing in the Bug Fest environment.
9. Finally, when the issue has passed test in the Bug Fest environment, the PO should change the status to Closed.
Bugfix release process
Bugfix = a fix release that happens after the module release deadline, but before the actual release.
- Bugfix = fix that happens after the module release deadline, but before the actual release.
- Set Release field of the bug Jira issues and let the developers doing the fix know that it is needed ASAP for a bugfix, definitely before the actual release. Do not confuse with the Fix version field, which should reflect the release version the fix will be included in.
- Label the bug Jira issues with bugfest_<Number> if the bug is found by a community tester during BugFest (this allows us to keep statistics on the bugs produced during that process. Don't forget to link Jira issue to TestRail test case.
- Use label regression when applicable
- Get the issue fixed and test on https://folio-snapshot.dev.folio.org/ (if possible - some performance issues that don't repro on snapshot will have to skip snapshot testing and be tested on the Bug Fest environment, instead)
- No permission is required for bugfixes before the release deadline. Once the fix has passed testing in snapshot, change the status to the "Awaiting release" and ask the module maintainer to create a bugfix release.
- You can get the module maintainer’s name from the Team Module Responsibility Matrix.
- The release needs to go to the appropriate Release branch and the Main branch.
- When the release is made, the module maintainer will announce it on the Slack #releases channel.
- Create a release ticket for the module and assign Bugfix Epic IN PROGRESS . Make sure that each bug in the release has the correct release version assigned to it. When the release has been created Change the status of the release ticket to Closed.
- The module maintainer will change the bug issue's status to Awaiting deployment. There is no need for the PO or module maintainer to request that the release be deployed.
- Jenkins robot automatically generate pull request for the release branch of Platform Complete repository in Github for every released module if version incremented by "patch" number. (For example from 1.1.1 to 1.1.2)
- Manual intervention required if release version requires change of major ( ex. 1.1.1 to 2.0.0) or minor (ex.1.1.1 to 1.2.0) number. In this case PO or Dev lead have to notify DevOps and Anton Emelianov (Deactivated) about this change.
- Folio hosting team checks for updates of Platform Complete one time per day and updates Bug Fest system with modules that have been released since yesterday's update.
- Folio hosting team will post notification in #bug-fest Slack channel when update starts and ends.
- Once daily update has been deployed to Bug Fest, Anton Emelianov (Deactivated) will change the bug issue's status to In bugfix review which is the PO's trigger to do the final round of testing in the Bug Fest environment
- Finally, when the issue has passed test in the Bug Fest environment, the PO should change the status to Closed