Please enable JavaScript.
Coggle requires JavaScript to display documents.
Release On-availability/demand, CL1 = Day0, CL2= Day1, CL3= Integration…
Release On-availability/demand
SW baseline is dynamic, meaning we include what is available
Gives us the ability to mix and match based on Customer roadmap/need
Removed version-dependency and minimized the TS delay due to one component being late or having errors.
Reduce dependency between tracks
Reduce dependency to external Teams (Balder)
Reduces POD prep lead times (CI + get what is available)
Easier to align with platform releases
Easier to troubleshoot and reproduce issues
Based on ToL but with bonus of testing features that are highly demanded by Market.
Releases are dynamic, meaning we release when we have confidence in what we have tested
When extensive testing has been performed on a set with CL4+ then we aim for PRG
Release team is overseeing each track, rather than steering.
Release process (only deltas) will be part of team activity
Releases have tags and instead of Release Notes, we could apply changelog.
No change to Jira structure, but change will be required from WoW perspective
Teams take greater responsibility to breakdown tasks with estimates in Team EPIC
Team EPIC uses tags to populate estimated release in Release Planner
Release Planner triggers PCPB creation with F4 dates (will require some manual work from OPO/RL team)
Future proof with CI/CD coming in later = CL5 enabler
Follows the Cloud-Native model
CL1 = Day0
CL2= Day1
CL3= Integration with traffic
CL4=Resilience/Robustness
CL5=Automated CL4