What is it to be loved?
At GitLab, we use a maturity rating to signal the readiness of a product category's capabilities for use by customers. The rating is evaluated by a scoring methodology called Category Maturity Scorecard. In 2017, GitLab declared Continuous Integration "Lovable" after delivering significant feature functionality and becoming a CI leader.
In the Verify Stage, we have been able to maintain a lead against our competition by adding advanced feature functionality, relying on our Single DevOps Platform, and executing on a strong vision. As the tides have been changing and as a practitioner of transparency, we articulate when we change our mind, especially when we learn new facts.
In a recent opportunity canvas, we explored the adoption hurdles that prevent Source Code Management Enterprise users from adopting Verify functionality. We explored all potential features as candidates for adoption across Verify categories - CI, Testing, Pipeline Authoring, and Runner.
In this blog we will dive into they key takeways that help answer the question of what is it to be loved and how the expectations have shifted over time, and what the path to Lovable maturity looks like for Verify:Continuous Integration!
Key learnings from the research
We spent 6 weeks interviewing and collecting insights from across our customers to learn about their adoption journey with GitLab. These were the main learnings informing our approach.
GitLab is loved by developers
Across each organization, we learned that the experience for the developer was resoundingly positive and the leaders at these organizations appreciated this. The happiness of their engineering teams was and will continue to be extremely important to them, but the fact that GitLab was a significant contributing factor in developer job satisfaction was a reward on its own.
GitLab has some challenges with performance of minimal viable changes that are expected to work at a higher finish
Enterprises are often larger, mature organizations shipping their own enterprise class solution. When faced with serving their needs, we learned they have a low tolerance for experimentation and a high expectation for polished features. This means a Premium or Ultimate tier offering needs to completely solve the problem and delight the user, not partially solve the problem. With our MVC and iterative methodology, we have historically shipped first and second iterations of features that may have solved the needs for individuals or small teams in small or medium-sized businesses. Although, with the expanding budgets as well as focus on developer productivity, organizations are looking for tools that will solve problems the best way possible, as comprehensively as possible.
GitLab's visibility into jobs at scale is painful, which also makes the management of diagnosing problems even more challenging
We learned a common question that organizations are unable to answer is around trends for passed and failed jobs. This is particularly relevant for projects that have over 100,000 pipelines and 300 jobs in single pipeline. Today in GitLab, there is no view where they can answer a question like how many times a particular job has failed; is it failing more often lately; does it fail at the same time each day; and other job behaviors of interest. Even filtering the job view is not possible today. So, for an organization that is looking to use GitLab at scale, it could be really challenging to easily triage and diagnose problems with their pipelines.
Path to Lovable
In the Verify 1H Direction, we identify a key piece of our strategy is to future-proof ourselves by investing in the core areas driving CI today. These top focuses include:
- Artifacts - these are essential assets for your jobs and pipelines, getting these performant will help users take advantage of features like parent-child pipelines.
- Variables - permissions and behaviors in pipelines are controlled by variables. Enabling these to work as designed will unlock the flexibility users have been looking for in their pipelines.
Be sure to stay up to date on the What's Next & Why Section of Continuous Integration's Direction page, which will link to specific scheduled issues.
Beyond this push for usability, in the 2H, we plan to tackle the challenges of visibility in diagnosing jobs via gitlab&5022 and piplelines activities in gitlab&5071, which you can see more information about in the Maturity Plan for Continuous Integration.