Epic Goal

• Rapidly take a hot fix to the cloud services:
  • Code gets checked in, pipeline build, downstream validation
• WE MEAN HOT FIX PATCH TO EXISTING FUNCTION
  • We are not delivering new features in this route

CICD's purview:

• Post PR merge: Post code change push to pipeline…
• Downstream build is ready for handoff to QE

Why is this important?

• Cloud Services have an uptime SLA that must be guaranteed
• Managed Services squad awareness
  • This is culture: being in a ‘hot fix’ ready position 24x7
  • QE: what level of testing in the context of faster validation
    • Clear articulation of ‘the PR’ handed to QE for scoped validation
    • QE needs to be in position to test specifically against the hot fix
    • QE needs capacity/availability
  •  Engineering has capacity and green light to put hot fix above all else

Scenarios

1. Customer encounters issue in cloud service code
2. high priority issue drives alerting to support
3. support triage moves quickly to engineering for evaluation of RCA
4. meanwhile during RCA, code is being updated and readied for PR merge
5. hot fix build verification test is readied
6. hot fix PR and built code is handed to QE for validation
7. new code gets pushed to cloud service

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• Some level of verification test is necessary, what level really is the question.

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions:

1. How much QE automation will be in play to verify the fix?
2. Does CICD need to manually roll back other PRs that are in the current build so that a clean hot fix can be built?
3. How rapid is Rapid?
4.  tradeoffs in quality validation: We can get more rapid via cutting out build VT and handing quickly to downstream QE

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>