-
Epic
-
Resolution: Done
-
Critical
-
None
-
None
-
Progressive Delivery process for the HyperShift Operator
-
False
-
None
-
False
-
Not Selected
-
To Do
-
Impediment
-
0% To Do, 0% In Progress, 100% Done
-
0
-
0
-
0
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.
- blocks
-
ACM-2155 Hypershift operator continuous delivery to Service Delivery
- Closed
- is related to
-
HOSTEDCP-2005 Progressive HyperShift Operator delivery for ROSA/HCP
- To Do