Uploaded image for project: 'OCMUI - OpenShift Cluster Manager UI'
  1. OCMUI - OpenShift Cluster Manager UI
  2. OCMUI-2372

Pre-merge testing: prerequisites and followups

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • pre-merge testing requirements
    • True
    • Hide

      Giving Assisted Installer until 1st week of October to decouple from the OCM UI codebase/repo.

      Show
      Giving Assisted Installer until 1st week of October to decouple from the OCM UI codebase/repo.
    • False
    • To Do
    • OCMUI-2062 - Pre-Merge Testing & Updated Promotion Process
    • OCMUI-2062Pre-Merge Testing & Updated Promotion Process
    • 0% To Do, 0% In Progress, 100% Done
    • (10/22) mortegag: finishing some tasks. I think next week will be available.

      Need to create stories to account for whatever 'day of' or 'preparing for day of' steps required to actually switch over to pre-merge testing AND the promotion to production steps (+ release notes, removing 'held back' list, etc.)

      Generally, steps like:

      Before Wed. Promotion:

      1. code freeze
      2. ‘sync-branches’
      3. QE to validate master
      4. Update to our documentation
      5. Would need a new way to generate/broadcast release notes. 
      6. decommision/delete ‘Held Back’ wiki?

      On Wed. Promotion:

      • If all of the above is in place, then on Wed. Promotion we can promote master/Staging ‘as is’ to stable/Production.

      After Wed. Promotion:

      • Would need to finalize and publish new QE and Dev roles and procedures for MR handling
      • Would need to change in GitLab MR’s ‘# Approvers required’ from 2 to 3.
      • Would need to add a checklist for QE reviewers. jmekkatt@redhat.com suggested something like:
        1. Created/updated test cases for the MR code changes.
        2. Pre-merge testing - Tested the MR code changes local OCMUI launched via reviewx tool.
        3. Closed all open issues/bugs found during MR pre-merge testing.
        4. Completed "QE" peer reviews on test case changes.
        5. Got the "tc-approved" label from Dev for the test case changes on respective jira card.
        6. Implemented automated tests for MR changes (optional)
      • Once above is done, we can start officially requiring Pre-Merge testing before merging MRs into staging.

       

            Unassigned Unassigned
            dtaylor@redhat.com David Taylor
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: