-
Epic
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
rhdhpai components release processes
-
False
-
-
False
-
To Do
-
-
Epic Goal
- Create a release process for each one of our RHDHPAI components.
- Ensure that our components follow a structured versioning, so that our development environments (team's dev RHDH isntance, ai-rolling-demo) can consume them while remaining stable and don't fetch breaking changes by accident.
Why is this important?
- Mostly it ensures that our staging env remains stable (rolling demo env) and is not affected each time by latest changes.
Scenarios
- Right now we use the latest tag for plugins. Imagine an update is pushed for a dynamic plugin and the rolling demo is restarted for an unrelated reason. The updates of the dynamic plugin are consumed without getting tested first so the new rolling demo version has an issue.
Acceptance Criteria (Mandatory)
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
- ...
Dependencies (internal and external)
- ...
Previous Work (Optional):
- …
Open questions::
- …
Done Checklist
- Acceptance criteria are met
- Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
- User Journey automation is delivered
- Support and SRE teams are provided with enough skills to support the feature in production environment