The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
|Content Last Reviewed||
Thanks for visiting this category direction page on No-code Automation in GitLab. This page belongs to the Low-code / No-code Single Engineer Group within the Incubation Engineering Department and is maintained by @astao (E-Mail).
This direction page is a work in progress, and everyone can contribute:
Work items such as issues and merge requests are the backbone of project planning and delivery in the GitLab application. Project managers are typically responsible for defining processes to drive work items from creation to completion through custom stages. As organizations grow, manually performing these repetitive tasks becomes increasingly counterproductive and error-prone.
No-code Automation offers an intuitive UI allowing project managers to visually build and manage their processes with triggers, conditions and actions to form the if-this-then-that-rules. Once the rules are defined, GitLab can perform the tasks behind the scene as soon as certain events occur, which keeps the work items up to date while helping project managers to focus on the more important duties.
The lack of automation rules for project management means inefficiency and inaccuracy in task triaging and status reporting. Beyond affecting the project managers, the strenuous manual tasks may also trickle down to other team members and impact their capacity. In other cases, not responding to feature requests or other backlog items on time could cost businesses opportunities.
A small number of customers are able to leverage gitlab-triage to build automation rules. However, the high barrier to entry (requires coding and hosting) and inconsistent experience prohibits most project managers from adopting the solution to automating repetitive tasks.
Workflow automation is an excellent technique to improve efficiency, and most project managers do not have a programming background. The immediate problem to solve is to allow the automation rules to be defined without writing code.
How do we differentiate ourselves? Jira Automation is a UI-only product for automating project management. GitHub Actions is code-only and mainly used for addressing complex CI/CD use cases. Our vision for No-code Automation goes beyond project planning to cover all stages in the DevSecOps lifecycle. We envisage a hybrid model that allows Automation built by UI and code to interoperate, bringing the best of both worlds.
To address the problem iteratively, we will start with an MVC to productize
gitlab-triage by fronting it with a no-code workflow builder while keeping the underlying Domain Specific Language (DSL) as-is. This approach will accelerate the Time To Market (TTM) and allow us to start iterating on the UX based on customer feedback while extending the DSL to support taking actions in other DevOps stages.
Eventing: Given the existing solutions and the limited capacity of this work stream, we are not building a new eventing architecture for triggering automation rules. However, a generic and more scalable pub/sub architecture, and an extensible eventing framework, are highly desirable to realize Automation's cross-stage vision.
We are very interested in participating in the solution proposed by the Pipeline Execution Group to make sure it can support Automation's use case, and we can eventually migrate over. We're currently doing discovery on the automation triggering capability.
Flow-chart builder: After prototyping with both approaches, we've decided to go ahead with the web-form-based UX over flow-chart for its compatibility with
gitlab-triage, the minimal learning curve, and overall simplicity. We keep this decision as a two-way door and are prepared to change our minds based on customer feedback.
Adoption rate: We will use Action Monthly Active Users (AMAU) to track automation rule creation and edit on monthly basis.
System Usability Scale (SUS): We will conduct feature specific SUS surveys to measure the overall usability of the feature.