Poppy (R2 2023) PO Bugfix Release Process:

Owned by Oleksii Petrenko
Last updated: Jan 18, 2024

Bugfix = a fix release that happens after the module release deadline, but before the actual release

NOTE: We are in the Poppy R2 2023 Bugfix period. Bugfix instructions are here;

(Prior Bugfix procedures are saved with the appropriate release.)

This describes the Poppy R2 2023 Bugfix release process (fixes being released after the initial release, but before the final Poppy deadline). This may be adjusted for future releases

  1. Bugfix = fix that happens after the module release deadline, but before the actual release. Please refer to the Poppy Release Schedule Most of these issues will be identified during Poppy R2 2023 BugFest Prep
  2. Update several fields in the Jira bug issue
    1. Make sure the priority is aligned with the definitions here: /wiki/spaces/DQA/pages/2657909
    2. Release field = Poppy R2 2023 Bug Fix
    3. Assign label bugfest_r2.2023 if the bug is found by a community tester during BugFest. This allows us to keep statistics on the bugs produced during that process. 
    4. Fill in the RCA (root cause analysis) field of the Jira, or else be sure that the Developer fills it in. 
    5. Link the Jira issue to the appropriate TestRail case(s). If there is no TestRail, create one, and then link to the bug.
  3. Let the developers doing the fix know that it is needed ASAP for a bugfix, definitely before the Poppy official release. Do not confuse with the Fix version field, which should reflect the release version the fix will be included in.
  4. 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)
  5. No permission is required for bugfixes before the release deadline. Once the fix has passed testing in snapshot, change the status to Awaiting release and the Resolution to Done, and ask the module maintainer to create a bugfix release.
    1. You can get the module maintainer’s name from the Team Module Responsibility Matrix.
    2. The release needs to go to the appropriate Release branch and the Main branch. 
    3. When the release is made, the module maintainer will announce it on the Slack #releases channel. 
  6. Create a release ticket for the module and assign  FOLREL-590 - Getting issue details... STATUS . Be sure that each bug in the release has the correct release version assigned to it.
  7. When the release has been made, 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
  8. Jenkins robot automatically generate pull request for the "R2 2023" 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)
  9. Manual intervention required if release version requires change of major (1.1.1 to  2.0.0) or minor (1.1.1 to 1.2.0) number. In this case PO or Dev lead  have to notify DevOps and Yogesh Kumar  about this change.
  10. FOLIO hosting team checks for updates of Platform Complete one time per day and updates Poppy Bug Fest with modules that have been released since yesterday's update.
  11. FOLIO hosting team will post notification in #bug-fest Slack channel when update starts and ends. 
  12. Once daily update has been deployed to Bug Fest, Yogesh Kumar  will change the bug issue's status to In bugfix review 
  13. When an issue is moved to In Bugfix Review, the PO and/or community should do a final round of testing in the Bug Fest environment
  14. Finally, when the issue has passed test in the Bug Fest environment, the PO should
    1. add a new test result to the TestRail case, which will hopefully move the test from Blocked or Failed to Passed.
    2. change the Jira Status to Closed


ECS CSPs

1. ECS Bug Fixes Submission

   - POs and other relevant parties follow the established process to submit CSP requests for ECS bug fixes. Specify if the request is for ECS.

2. Streamlining CSP Request Reviews/Approvals

3. Development and Testing:

   - The development team works on a fix within their development environment and conducts thorough testing.

4. Fix Deployment to Poppy Bugfest ECS Environment:

   - The development team releases (including merge into master) the fix and deploys it to the Poppy Bugfest ECS environment. (Use our standard DoD)

5. Verification on Poppy Bugfest ECS Environment:

   - Once verification on the Poppy Bugfest ECS environment is successful, the fix is deemed ready for deployment to MOBIUS.

6. Deployment to ECS Dress Rehearsal Environment:

   - The fix is deployed to the MOBIUS Dress Rehearsal environment for verification by MOBIUS.

7. In parallelwith #6 (i.e. NOT waiting on Mobius’ approval),  verification on Poppy Bugfest Non-ECS Environment (regression testing)

   - Simultaneously, the fix is verified on the Poppy Bugfest non-ECS environment. If verification fails in the non-ECS environment, steps 3-6 are repeated.

(At this point, master has been verified for both ECS and non-ECS and is ready for Prod deployment)

8. Official CSP Version Release:

   - Once the fix is successfully verified, an official CSP version is released, ensuring proper identification of ECS fixes within the CSP.