💡 Workflows Solution Validation
What's this issue all about? (Background and context)
Plan-specific
Customers and prospects frequently express the wish for a way to easily manage end-to-end workflows (Epic, Issue, MR...) within GitLab.
Competitors have taken a wide-ranging approach to solve this core set of JTBD within their respective products.
- Jira Workflows
- GitHub Project Automations / GitHub Actions
- Asana Rules
- Monday.com Automation Recipes
- Data Dog Workflows
There is a wide-ranging set of desired functionality when it comes to managing and automating workflows that typically all boil down to answering these questions:
- Status - Which workflow stage is a work item currently in?
- Automation - How can I automatically transition a work item from one stage to another based on trigger event and set of conditions.
- Enforcement - How can I prevent the transition of a work item to another stage unless certain conditions are met.
- Analytics - Where are the bottlenecks in our workflow? What is our throughput? Are we improving? Is our productivity increasing?
Right now, GitLab can only partially answer a few of these questions. Status is not a native concept and users must rely on scoped labels. The only way to handle automation is by writing custom scripts or using gitlab-triage
, which is not natively part of the GitLab experience. There is no possible enforcement of anything when it comes to issues and epics. The closest analytics solution is our Value Stream Report, but it is fairly broken at this point in time and requires a lot of up-front configuration to be able to tie a scoped label-based set of workflow stages to a Value Stream report.
The broader, cross-stage opportunity
Goal: Provide a competitive differentiator to GitHub Actions that is inclusive of all GitLab stages.
- Leverage platform events specification (CloudEvents) as the underlying architecture to drive a standardized interface to facilitate eventing among GitLab's internal product surface area as well as with third-party integrators.
- Leverage existing work done by the Event Stream Working Group
- Other technical benefits -- #355658 (comment 881835570)
What hypotheses and/or assumptions do you have?
- We can leverage the CloudEvents protocol to build a robust eventing architecture that can be used to power automation and workflows across stages.
- Having a stage-agnostic architecture will enable all stages to integrate eventing for their GitLab objects, which will increase the value of a native automation framework within GitLab. This in turn will drive a significant increase in SpO.
What questions are you trying to answer?
- Is leveraging CloudEvents the right direction to go?
- Can we effectively organize a cross-stage initiative around a native automation framework that can be inclusive of all GitLab stages?
- What should the configuration look like? YML, database, a mix of both?
- Is it usable?
- Is it technically feasible?
- How would we replace our current events/webhook implementation with the new CloudEvents protocol?
- Would a consumption-based pricing model be a viable monetization strategy for this capability?
What research methodology do you intend to use?
- Opportunity canvas (internal only)
What persona, persona segment, or customer type experiences the problem most acutely?
- 🟩 Most
- 🟨 Moderate
-
⬜ ️ Limited
- 🟩 Software Developers
- 🟩 Development Team Leads
- 🟨 Application Development Director
- 🟩 Product Managers
- 🟩 Software Engineer in Test
- 🟨 Product Designers
- 🟩 DevOps Engineers
- 🟨 Security Operations Engineers
- 🟩 Release Manager
- 🟨 Security Analysts
- 🟩 Application Ops
- 🟩 Platform Engineer
- 🟩 Compliance Managers
- 🟨 Systems Administrator
What business decisions will be made based on this information?
- Prioritization
- Most likely the direction of various overlapping initiatives across different product teams.
What, if any, relevant prior research already exists?
Who will be leading the research?
What timescales do you have in mind for the research?
- Complete by FY23 Q3
Relevant links (problem validation issue, design issue, script, prototype, notes, etc.)
Overlapping & Complimentary Efforts
- Research: Scope next iteration of reactive triage (gitlab-org/quality/engineering-productivity/team#10)
- Platform Events (#355658)
- https://docs.gitlab.com/ee/user/application_security/policies/#policy-editor
- https://docs.gitlab.com/ee/administration/audit_events.html
- https://about.gitlab.com/company/team/structure/working-groups/event-stream/
Business Case
Officially requested by 14 distinct accounts and is the third most requested / highest value capability from the Plan stage.
Other related issues this would solve:
- Configurable Work Item Statuses (&5099)
- Provide buttons to transition issues between is... (#33815)
- Custom workflows - Group configuration (#2059)
- Create workflow key-value labels (#9366)
- GitLab Automations (&218)
- Platform Events (#355658)
- Recurring issues (#15981)
- Allow to execute post merge quick actions (#212166)
- Configure default assignee for issues (#14585)
- Automatically add label based on issue template (#16146)
- Improve automation in Issue Boards (#241773)
- Automatically remove workflow labels, when an i... (#242040)
- Configure label to be removed when issue is clo... (#17461)
- Scheduled triage support (&636)
- Automatic Triage and Labelling (#30748)