Epic Goal

• Move the OLM team to support Openshift 4.Next
  • Master branch is stable as measured by CI and SLOs
  • Not merging or exposing functionality until it is complete and stable (No-FF process, feature flags, etc.)
  • Delivering a stable and usable payload every sprint
• Process should be documented and repeatable for other projects (e.g. RukPak, Deppy, etc.)

Why is this important?

• Organizational shift
• Deliver what the customers need, faster

Acceptance Criteria

• OLM CI infrastructure now delivers the 4.Next way

Dependencies (internal and external)

1. ...

Open Questions

• Can we use this process to expose alpha/beta/non stable features for end-user testing and feedback?
• How to handle up/downstream skew?
• Do we need to change team processes, e.g. alarm on master fail and, e.g. BugDocCop has to root cause/clear the pipeline
• Do we want to move away from the mono-repo?

Resources

• Feature Freeze Proposal Refined
• Current State and Feedback on the No-Feature Freeze Proposal
• Idealised Workflow

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>