GitLab UX Team, 15 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Auto DevOps - Working by default

Description

Aligning the UX of Auto DevOps and CI/CD: https://gitlab.com/gitlab-org/gitlab/-/issues/280572
Auto DevOps Adoption: https://www.youtube.com/watch?v=i7qL1dS5x8g and https://gitlab.com/gitlab-com/Product/-/issues/1801
Auto DevOps moving to Pipeline Authoring: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/69515

A

Hey team- some of you already saw me yesterday, talking about our new product principle working by default and the ux weekly call today. I want to dive a bit deeper and show how we currently violate this principle in some of the areas in our current product.

A

So let me jump over to gitlab and, let's imagine I want to start a new project either for professional use or a new site project, so I jump in create a blank project.

A

Call it blank project, make it public and already initialize the repository with the weedme.md, so that it's easier for me to afterwards clone it and get it locally, create the project and because I really care about building a secure and well maintained product. I want to enable all security features from the beginning on and when I jump to security configuration.

A

What I'm seeing is that very prominently. We have a banner here that tells me I can enable all security scanning tools by using auto devops. Also, it's exactly what I want. So I hop on over to the settings I default to auto devops pipeline save my changes, and now I assume I'll. Just have to wait for the first pipeline to run so, let's wait here until the pipeline finishes for the first time, so after 5 minutes and 13 seconds.

A

This is where I'm at now my build is failing, which causes probably also test fail, which means that I won't get to secret detection and container scanning, even in a project where there's nothing except for a readme.md.

A

I understand that there might be cases where it's tough to get autodevops to work, but there shouldn't be one. We should be testing for some for things like this and make sure that when a user starts using a project on gitlab.com and wants to enable a feature like autodevops from the beginning on that's the case that should work.

A

So when I wanted to then see how autumn devops would actually work, I decided I would create a new project and actually use one of the templates we created and I chose nettle fire jackal I just choose chose one randomly could have been any other one. That's the one I chose and let me show you what happened.

A

I enabled autodevops and exactly the same thing on the first one of the autodevops pipeline.

A

I get built failing and the big big problem of this is we advertise auto devops as the way to use and to start enabling secure features as one example also more other features, but secure features as one big target and seeing that a failing, build job skips all other parts.

A

This means the user won't have direct access to all these secure features, because another part of our pipeline is failing. Secret detection.

A

Dependency scanning, all these aspects are not working in auto devops, because the build is already failing, and so I decided to compare this with github and what I'm quickly going to do is just take the same repository that we can't run right now, auto devops on which means, as that's the primary way, that's being advertised here for enabling all these secure features. I want to see what the experience is on github for enabling their secure features.

A

So let me do this and begin the import.

A

This should hopefully run rather quickly, so I'm not going to pause here, but what I really want to do is compare what the mechanism is between enabling features and starting to use them on gitlab versus on github.

A

So now I'm here in my new repository and what I'm already being greeted with is we found potential security vulnerabilities.

A

I didn't even have to enable it, which is very interesting- and I see already the security tab has three alerts, so I jump in here and I see what alerts I'm getting.

A

And when I go in here, I get information and what also just happened in the meantime, I'm seeing pull requests being created that are supposed to help me upgrade and make my repository more secure.

A

It pushes me to upgrade from jekyll 3.4 to 3.6.3 and all of this without me, configuring anything.

A

There's another discussion to be had whether this would be a great experience for projects with a lot of security alerts and getting a lot of pull requests. But what you can see is how fast, how direct how quick it was to use these features here. How these security features didn't depend on something like our auto devops pipeline to succeed, and I know that we can also use these security features by themselves.

A

But this is absolutely not easy to understand and easy to see for the user. Here you can see every time autodevops is being mentioned. All to default is being mentioned, it's marketed as the primary way to use and to start using security features, and there are absolutely more examples like this, but this one really stood out to me yesterday, where it was extremely tough for me to get auto devops to work. I couldn't get it to work on empty projects.

A

I couldn't get it to work on our own templates and taking our own template, something that we have control over, bringing it to github. It directly worked, and it directly gave me a way better experience from a configuration and enable enabling the feature standpoint than we currently have.

A

So let's take this and make sure it works better in the future. Thank you all for watching.