Details
-
Epic
-
Resolution: Done
-
Critical
-
None
-
None
-
None
-
Progressive Delivery process for the HyperShift Operator
-
False
-
None
-
False
-
Not Selected
-
To Do
-
Impediment
-
100
-
100%
-
0
-
0
-
0
Description
User Story
As an SREP engineer, I want a progressive release process so that I can improve reliability of the ROSA service by minimizing risk to code changes.
Acceptance Criteria
- Each SREP artifact that is part of delivering/operating a managed ROSA+HyperShift cluster has implemented progressive delivery as described in SD-ADR-0032 : HyperShift: Change Management Strategy.
- See SDE-2099 Release process for ROSA/Hypershift components - phase 1
Default Done Criteria
- All existing/affected SOPs have been updated.
- New SOPs have been written.
- Internal training has been developed and delivered.
- The feature has both unit and end to end tests passing in all test
pipelines and through upgrades. - If the feature requires QE involvement, QE has signed off.
- The feature exposes metrics necessary to manage it (VALET/RED).
- The feature has had a security review.* Contract impact assessment.
- Service Definition is updated if needed.* Documentation is complete.
- Product Manager signed off on staging/beta implementation.
Dates
Integration Testing:
Beta:
GA:
Current Status
GREEN | YELLOW | RED
GREEN = On track, minimal risk to target date.
YELLOW = Moderate risk to target date.
RED = High risk to target date, or blocked and need to highlight potential
risk to stakeholders.
References
Links to Gdocs, github, and any other relevant information about this epic.
Attachments
Issue Links
- blocks
-
ACM-2155 Hypershift operator continuous delivery to Service Delivery
- Closed