The Release Management group is focused on all the functionality with respect to Continuous Delivery and Release Automation.
You can also reach out to the Release Management Slack channel #g_release-management.
We are working on adding depth and enriching the Release Management features to support our vision of allowing users to plan and orchestrate releases from wherever they want API, YAML, and UI. Our next big items are:
We are also continuously investigating how to improve the overall user experience of GitLab Releases through the following initiatives:
The product vision for Release Management has become more focused on providing advanced administration capabilities for release coordination and deployment tracking in GitLab. This is to build on the data asset we have at GitLab that starts from users purchasing GitLab to build product fast in a continuously integrated way. We will expand this journey by helping them coordinate and deploy at scale.
Today, mono-repository projects deploying with Kubernetes are most able to take advantage of our offering. We are targeting customers needing to coordinate across many teams and groups to successfully deploy. Regulated industries are top benefactors of our offering.
See all Release Management competitive analysis.
See all Release Stage Jobs To Be Done.
workflow:design, they don't need to have a milestone assigned and are mostly assigned to Backlog. UX and PM will discuss the scope and priority of these in our 1:1s, ThinkBig! sessions, and other sync and async methods. Once a design proposal is added to the issue description (SSOT), we remove it from the epic and move it to the next step as per the engineering workflow stages.UX, devops::release and group::release-management.workflow:ready for design before moving them to workflow:design.UX, creating follow-up issues, and updating the SSOT as the scope of delivery changes.
This is a pilot process we kicked off in 12.10 – release-management#21. Iterated on release-management#40.
Together with the product manager, the product designer applies the DoD to epics in order to better break down design work and give counterparts better insight into which steps in the design workflow need to be completed before the MVC can move to the development phase.
### UX Definition of Done
- [ ] Problem has been validated
- [ ] Problem is ready to enter ~"workflow::ready for design"
- [ ] User stories and acceptance criteria for MVC have been created
- Reminder: consider edge cases for each user story
- [ ] Cross-team dependencies have been identified, if applicable
- [ ] Prototypes or mock for each user story have been created
- [ ] Solution has been validated
- [ ] Pajamas
- [ ] UI Component design have been identified
- [ ] Pajamas issue is created (new workflow)
- [ ] If changes involve copy, ~"Technical Writing" and ~"UI text" labels have been added
- [ ] SSOT of MVC has been updated and labeled ~"workflow::ready for development"
See how other designers in CI/CD use the UX DoD
We collaborate closely with the engineering team to ideate, refine, review, and iterate on the design of Release Management features. The Product Designer's responsibilities include:
UX debt.Watch on Unfiltered: Frontend/UX MR Review Process. What can we improve going forward?
Chart (Sisense↗)
Chart (Sisense↗)
Our Release (CD) UX YouTube channel includes UX Scorecard walkthroughs, UX reviews, group feedback sessions, team meetings, and more.