GitLab Pipeline Execution, 1 Apr 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Project level insights around pipeline performance

Description

For feedback on a new proposal.https://gitlab.com/gitlab-org/gitlab/-/issues/357528

A

Hi all I'm vaitika the senior product designer for pipeline execution, and I am going to talk about some changes in proposals for the issues which are a part of this epic that says, provide ci cd, analytics and observability data.

A

Today we do have all the many issues that are part of this epic, but these were created long back and the information that we were working with around that time. They were not as elaborate and not as did not have a lot of depth to them.

A

So as we have come along, as we have spoken to more customers, more users conducted new interviews, we've been able to uncover a lot more information, uh and so I thought it would be a great idea to first kind of refine the insights so that uh what we, whatever we proposed next should be uh like, should should provide a lot of value and impact to our users jobs every time all right. So what I did was I revisited a lot of old researches customer calls user interviews.

A

I also conducted some new user interviews and putting all of those data together. I very critically assess them and try to derive some insights from them, so the first insight is reduce the time it takes to analyze pipeline performance. Speaking to a lot of users, we figured that at some point or the other, every organization needs to get their hands on a performance report for their pipelines and jobs.

A

It's not that it's not possible today to create those just that it is very tedious and a very difficult job because they have to take into the pipelines and jobs independently one by one and it it ends up consuming a lot of their valuable time, which is not ideal. We should provide these like. We should keep this information ready for them to consume at any time, and also handy next. Is users desire a holistic trend report for pipelines that include the runner, infrastructure and environments, so pipelines alone, don't tell the complete story.

A

It is only when you put them into context like which branch are they running, for that tells like which committees they're, trying for or um which environment did the vibrant run for those are the critical pieces of information that add more context to the uh like to the insights that we're present presenting.

A

So those those particular data points are equally important to users, uh along with how their pipelines are performing, past failure, etc. Then developers need to look at metrics that communicate real time status of the pipeline, so developers are the because of the nature of their uh job that they're performing.

A

They are more concerned about what is happening with the pipeline that I, uh that that's running for the emerge request that I created or a change that I pushed so they are more concerned about the health of that running pipeline rather than the uh trends um when the data is compared to their past performance.

A

Then. Lastly, users want to look at metrics that highlight trends and performance spotlights now. Information about pipeline performance can be presented in many ways, but everybody seeks to uh look at insightful information, something that tells them exactly what's going wrong and what is it that they need to act upon or what um action do they need to take to fix if something has been spotted if a bottleneck has been spotted?

A

So with these uh four insights, I would go back and again show like what are the existing issues that we currently have.

A

So we do have an issue around presenting information around pipeline performance in gitlab ci. But if you look deeper, if you look into the proposal the problem stated and the user experience goal, this mostly talks about the running pipeline. That means it only talks about the pipeline performance information, but for the pipelines which are currently running, and the proposal was that this would sit on the pipeline details page now.

A

This is one and the other one is: um should group level cicd analytics to get lab ci users, because if you could, we do not have anything at the high level uh for director level personas to quickly go and go to and get a quick glimpse of. The performance of the pipelines of the many projects that that comes under the their groups now both of these are great, but we need to first address this problem at a level where most personas would be able to make use of.

A

So if we present it at the pipeline details level. That means for one pipeline at a time. What we're missing out on is the trends like we are not talking about the historical um performance information like uh and we are not talking about the overall like we are not providing a report, which is what the users want at this point of time.

A

So that's something that is more associated with the development team lead and like uh software engineering, lead kind of roles and sres, but developers would also be able to make use of that information if they get to see like what are the jobs that have been historically fakie or historically uh problematic. They would be more careful about those vitals.

A

They are working with their current pipelines and if we show something at the group level only that means we are blocking the access to mentor the maintainer role, which is what most development uh devops engineers and team leads have.

A

So we shouldn't be um like we should be very careful about who we are blocking from accessing the feature now, keeping all of the information, the insights, the restrictions, the permission, related constraints in mind, there's a new proposal that I've come up with, which says, show project level, insights, run pipeline performance um and what it says is this is going to like this particular feature would focus on providing you a glimpse of what's happening to the what's happening, with the performance of the pipelines for a particular project, not group not singular pipeline, but the pipeline for the entire project.

A

Now it could be something really wide. So how can users use it to their own benefit?

A

So one thing that I proposed is: maybe we can have selections for branches for environments and even time, if, uh like our capabilities, allow us to do that, and it would be a very simple report to start with, which would only talk about like what's the success and failure rate of pipelines and what's the duration, that each job has run um on an average like what's the aggregate duration for the uh jobs, and this would also give like some single start report- uh information about the duration of pipeline in general, the aggregate duration of pipeline.

A

So those are the simple data points that we can start off with and uh we can develop them further as we go. I know that this proposal alone is not an mvc and that's why I'm sharing this video with you all, because I need your help to understand um how to break it. I would be putting down an iteration proposal inside this issue itself and I would really um appreciate you dropping your comments and suggestions and inputs there yeah. That's all. Thank you. So much.