GitLab GitLab Group Kickoffs - Manage, 16 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Manage 13.7 Kickoff

Description

Melissa, Haris, Larissa, and Jeremy talk about what's ahead for Manage in 13.7.
- Manage:Compliance - 0:34
- Manage:Access - 4:45
- Manage:Optimize - 15:26
- Manage:Import - 25:31

Agenda and issue links available at https://docs.google.com/document/u/1/d/e/2PACX-1vRnN91k9Rx1AyF8cIQga3KGFpjkI-sheTB16Jg-4e8fO3snZas2Th4hJC5C5wKIrNWbzr8aYDjI-T7-/pub

A

Hey y'all, uh I'm jeremy watson and I'm joined here by melissa, harris and larissa here, uh representing the access, optimize and import groups and uh we're here to kick off the uh gitlab 13.7, releasing december 22nd 2020 and we're going to talk to you through talk you through some really exciting changes that are ahead. um I am going to be representing the compliance group. This particular kickoff call. So without further ado. Let me go ahead and share my screen and we can get rolling.

A

So I'm going to be talking through a couple of really interesting changes. I think the first of which is going to be making a a list of user permissions per group and project available.

A

So in previous releases, we've added a series of api endpoints that allow us to pull a list of permissions for use for different users, and the challenge here that we're trying to solve is that it's kind of challenging in gitlab prior to prior to these changes to really understand what who has access to what um in 13.7 we're going to actually roll this up into a very useful csv report.

A

Where now you're going to be able to we're going to expose this export permissions as csv button and then you'll be able to get emailed a specific link to a csv that you can download via an email link in your email and then you'll be able to see a clear list of user permissions about a per group and per project basis, and this is super useful to help admit uh gitlab administrators really understand who has access to what in a single place and have a clear artifact, and it tells you exactly, uh gives you a clear picture of access control over the over your entire instance.

A

The other thing that I think is very cool is we're iterating on compliance frameworks. Project compliance frameworks are a really useful tool that we use for helping identify, different projects that are under uh controls like hipaa or sox, and but one request that we've had in the past has been well. I want to be able to define my own custom compliance frameworks and now in 1307, you're going to be able to do that.

A

We're going to be able to take those compliance frameworks and do very interesting things around applying settings out of the box that can help you stay compliant, but the first step is going to be allowing you to create, read, update and delete your own compliance frameworks. So now you can create and title your own, uh your own project frameworks and then with custom descriptions as well, so really excited about that and which is going to lead to some really great changes in the future.

A

The other change. The third change that I'm really excited about is going to be. The addition of group level merge, request approval settings. We really love the idea of being able to apply and manage mr approval settings at the group level. This is especially important for compliance use cases where you have a series of projects, and you want to make sure that they all adhere to specific settings that allow you to connect for segregation of duties like preventing approvers from from uh um from up from approving their own commits.

A

Well, now, you're going to be able to we're in 137 we're going to introduce a settings area and iterate on that in the future, to add more and more enforcement and uh and compliance settings in the future at the group level.

A

um The other thing is we're going to be adding gpgs to the admin credentials inventory, so the credentials inventory is a very, very useful, uh single source of truth in terms of credentials that lie across your entire instance.

A

We already have uh support for things like ssh keys and pats, but in 137 we're going to add gpg's keys to the list and then finally, a a change that I'm particularly excited about is we're going to take the audit event system right now, which is a um a system we use for logging and understanding what user driven events across the entire instance we're going to make it available for all roles. So previously, this was something that was only available to admins and and group owners and project owners and maintainers.

A

But now you're going to be able to see audit events for all roles and you will be able to see audit events for your own user. So while you won't be able to see, if you don't have, um if you don't have you know, owner or maintainer privileges across uh in gitlab you'll be able to see everyone else's audit events, but you'll always be able.

A

You should always be able to see your own, so we're hoping that this will make this feature more accessible, more useful for for our users and increase the level of transparency and help you understand kind of like what you're doing across across get lab. So that's really what's in store for the compliance group at gitlab, uh I'm love. If anyone has any questions or thoughts there. I'd love to hear what you have to say.

A

Cool, uh that's it for compliance um melissa. What's going on in access.

B

Hello, everyone, let me share my screen.

B

We have some exciting stuff coming up in this next release and the first one being further iterations on the group members list. I don't know if you've seen it, but we have a brand new members list which basically has separated out elements and basically you have a new table and the next iteration of that is filtering.

B

uh So now that we have uh separate data elements and we have a new table, that's using pajamas components. This allows us to do more sophisticated filtering on our members list and it'll. Look a little bit like this I'll. Follow the filter bar pattern and it'll just be a more intuitive way to filter users.

B

Right now, a big ask is for people to show direct numbers. As you know, today we show all members of the whole group in the table by default and it's sort of I'll show you what that experience looks like today.

B

It's not really intuitive how to filter further. Some of the filters are here. Some of them are down in the sort bar. So now all filters will be in the same place. It'll be really easy to know what you can filter by and in the future. uh This sets us up for where we can remember what you last filtered by and and it'll be really intuitive to see what's selected.

B

um So I'm super excited about that. uh The next change that we're working on is around building web hooks for uh groups.

B

uh So today we have web pokes at the instance level and at the project level, and we have somewhat folks at the group level but they're really just aggregation of project level events, um so we're going to be building uh web hooks for group objects and the reason why this is important is because, specifically for large customers, a lot of times, they'll have automation that is triggered based on events that happen in gitlab and right now we have some pretty large customers that are basically polling the api frequently to find out when something happens, because we don't have web book events for all of them, specifically around members joining a gitlab group.

B

Sometimes certain customers will have automation that happens to make sure they're in the proper groups. They have the proper roles they have. The proper attributes set to them, so this will help ease, um basically performance load for api calls on gitlab.com.

B

This is the first event, uh basically as an mvc, it will just be when members are added to a group and all basically all subgroups down the stack and then we'll build on to other events like changing the role, removing a user um etc. But this is the the first one and also when subgroups are added right, so we're going to go through and and basically work through the events for groups.

B

So I'm very excited about that because basically, when this is uh all finished, is all the issues that are in this epic um we'll be able to greatly reduce the api load on gitlab.com by one of our largest customers. So that's a really big win and next is a big item. That's taken a lot of discussion, and now we have an nvc. So I'm super excited for that.

B

You've heard me talk in these meetings around group manage accounts and accounts ownership, and how can we help some of our larger customers basically have greater control over accounts in their group and after a lot of discussions with legal and engineering we've arrived at a small mvc that I feel will make a big difference and it all hinges around the concept of how was an account provisioned right when we talked internally.

B

We could all agree that, when an account was provisioned by automation in the context of a specific group, then it's very clear that that account has a very specific purpose, especially if it's a brand new account that has nothing on it right. They haven't joined any other groups. It's very easy to basically have a very catered experience for that account as long as we do proper messaging to end users.

B

um So, in this milestone, we're gonna take the just-in-time sample provisioning aspects that gma had included and make that available um to all saml enabled groups right. So any saml enabled group um can basically have a way to create accounts automatically based on saml assertions, and then we will record basically the context that this account was created in. uh So we can say this account was created in back end right because that's not something that exists today. Even for skim provision accounts, we don't really know how an account was created. So we'll start recording.

B

This account was created in the context of this group by saml and then based on that we can send them a custom email that basically lets the user know that, because their account was created in the context of a group, basically only use it for this namespace and you may have some um greater control. That's asserted over your account because it's basically provisioned under this very specific context.

B

So this basically lets the user know and sets the right expectations for them about what this account, for, which is something that was problematic with gma and then, lastly, because these accounts were provisioned by a saml and and we've chosen saml as the first mvc, but this would apply to skim as well.

B

We just picked saml because of the specific uh customer that we're working with on this. um We can give, and you can think of this as provisioning settings right.

B

So if you are setting up your automation to create new accounts, we can give you specific levers that you can pull and and different attributes that the accounts that you provision can be can have, and the first ones that we're gonna choose are two that already exist for users, but they only exist today at the instance level right, because that's the only way that admins can create accounts today and there are two settings, the project limit and can create groups, and those can control basically where you can create groups and projects, and if you set these to the values that I have here, we can make it so that users only can create groups and projects within a top level group that they're already in so basically with this, we can it's a lightweight way of sort of giving a more exclusive to a top-level group experience for accounts that were provisioned under a top-level group.

B

So um this is the first mvc, like I said, there's a lot. The next uh part would be mimicking the same experience with skim and then from there. It would be tailoring more behavior right based on that accounts for provision and then further than that is converting existing accounts um to be kind of like managed as well and but that last piece um there's some legal terms and just user experience concerns.

B

um So it was much easier to start with fresh accounts brand new. They don't have any other data in them.

A

Awesome thanks a lot melissa. um What's the pricing plan for provision accounts? How are we thinking about that.

B

So I am thinking about it as a silver feature, um because, uh as I understand right- and I- and I know this can be debated like it's a silver or gold feature, um but as as I talk to more customers, um they expect that this is how gitlab.com works and it's actually quite surprising to them that it doesn't work this way. um So I feel like there's going to be significant pushback.

B

If we try to hear this higher right, because there's going to be an argument of basically, the default should be secure and there's a perception that accounts persisting outside of the group is insecure.

A

Cool awesome: are we going to move the awesome new members list of projects too? I really think it's awesome. Do you have does actually.

B

A

B

Yeah, we have issues for that, um but that will probably be the next milestone.

A

Yeah cool just curious paris. Did you want to voice over your comment.

C

Yeah, I'm totally plus one on that uh usability improvement. I mean that particular filtering. Slash. Sorting uh component was something that I struggled with, and people had to like jeremy. I think it was you who had to explain to me how that works and how to find people who are actually members of the group, not by inheritance I mean it was it was. It was really hard and I kind of had to go back and read that one more time again to be able to use it. So just doing that, thank you so much.

C

I think this is stuff that uh kind of really small things. Small usability, improvements that make a big difference out there so appreciate that a lot yeah.

A

We added that to that random sorting menu as like an mvc, but you know those paper cuts build up over time with more and more nbc's. It's really nice to see it's clean everything up like this. It's a really great experience and I'm also really happy to see the membership web hook being prioritized. It's probably not the sexiest feature on the outside, but I know that it's something that our customers are really looking forward to a lot of people.

A

It's a massive pain because they're constantly pulling for these changes and having a web hook, they can use for that. That's just is huge. So thanks a lot, that's going to be a great change!

A

Awesome! So larissa over to you.

D

D

All right, um so we have two areas of focus for this release. The first is value stream analytics and improving the navigation and user experience for that, and then, secondly, we are going to be making some more improvements to the devops reports so for value stream analytics.

D

We have this horizontal navigation along the top here and that um that's on by default on.com, but it's behind a feature flag for self-managed installations.

D

um We also have this vertical navigation, and so what you see on this page changes based on the context of uh what you're clicking along the top here, but also down the side which is confusing. It takes up a lot of space on the screen to have this vertical navigation, and it also pushes these charts further down the screen. So what we're going to do is remove this vertical navigation and just have this horizontal navigation at the top, and then we are also going to make it a little easier to create a new value stream.

D

So you can create your own custom value stream, but the process for doing that looks like you: could you click on create new value stream? You add a name and then you have to I'll just add a name, so I can show you and then you have to go down and add your custom stages into that stream down here.

D

So the improvement we're going to make here is that when you create a new value stream up here, you'll have more ui available in that pop-up, where you can add your stages directly in there and turn on and off the default stages.

D

And finally, we're also going to add an edit button, uh because the workflow for adding a stage at the moment is you have to scroll down to this vertical navigation with that going away, we'll be adding an edit button up here. So, whichever um whichever value stream you have selected here, you'll be able to click the edit button and change the stages that are available for that.

D

All right so that's value stream analytics and then for devops reports.

D

Today we have in the admin area, we have devops report and this is where you can see the devops score and that will show you your adoption of the different devops stages relative to other gitlab users, so using usage ping to collect that data and then comparing your adoption of each stage against the average.

D

So we are going to be adding a new tab here. So you'll have the devops score still, but you also have this adoption tab and in this adoption area, you'll be able to see your adoption of devops stages relative to other segments in your organization and segments is also a new concept that we're introducing in this release. So segments looks like this you'll be able to create a segment and a segment can be any combination of a group or a subgroup or projects.

D

So this will allow you to create a segment that might be specific projects within a subgroup and then adding some other other groups to that segment and then you'll be able to see a table like this. That will show your adoption of each stage by segment and compare those segments.

D

uh So that's that's what we have going on for optimize. Any questions on that.

A

Awesome thanks so much larissa. That looks really great. um I I do love the horizontal navigation, a lot more in vsa.

A

I think one consideration why we iterated them separately um was because the vertical nav was so mature and I think his harris points out, like you get like a nice overview of time spent in each of the stages, and we wanted to make sure that we could iterate on the horizontal bit in parallel and not have to. You know, move away from the vertical until we were really ready.

A

um I do like the horizontal nav a lot more, but um for me it still doesn't look clickable, and that was something I felt nervous about, because the the the vertical looks each one of those containers looks like you can click on them and the horizontal still doesn't. Look that so consider watching out for that. As that feature, moves along to make sure that, like an user user, is looking at the first time if they need to be able to know that they can click on this stuff to get more detail.

D

Yeah, that's a great point. Thank you I'll check the design and see if we have something built into that already.

C

To jeremy's point I did not know they were clickable like the horizontal was clickable. I thought it changed as I clicked on the on the left. It felt like something that just like auto puts you in the right spot, doesn't look like something you interact with it, just kind of tells you where you are, but it doesn't it's not like how I would what I would use to get there.

C

So from the from the ux perspective, I will agree with that and and then uh my concern was also the ability to see kind of an overview of the time spent in each one of the stages which you do have on the on on the left. Nav. I do see how it takes up so much space, so I hope there is a way to to actually be able to see that without using all that space up.

C

But what I found useful there was uh sort of just taking a glance at it and see if it just makes sense. Like you know, I should I kind of know like for any any kind of a uh business or for any kind of instance. I can have an idea of how long each one of those stages should take, so I could easily spot when something's off. If I can just sort of see those uh lined up there. So something like that, I find very useful. uh So is there?

C

Will there be a way to see that once it's removed.

D

Yeah, I was just looking through to see if I could find a design for that, but um I I believe the idea is to put that that measurement against the button on the horizontal yeah yeah.

C

That makes sense yeah.

A

I've seen designs so like unknown, just thinking about it, but so yeah you're absolutely right spot on here. It's like we need to have that in the that information right there in that, in that value stream.

C

And, of course, lawyers are just welcome to uh uh to to this position where you know, as soon as you take ownership of something the very next day, people are asking you questions like. Why wasn't this done three months ago? What was your long-term thinking on this right? Exactly.

C

That's just normal that just comes with the with the job.

D

Yeah, absolutely you can blame me for this three months from now. I.

C

Actually believe.

B

I just found a right.

D

I just found the design, so I'm just going to share my screen again really quickly, so you can see what I'm talking about. uh So do you see up here how we have the metrics alongside the navigation yeah, that's.

A

Actually, I think, that's.

D

What we're working yeah see.

A

This looks so clean to me, but it still doesn't look clickable like I. If I seen if I saw this.

D

A

The first time, I would have no idea that I could click on that, because the text in the value stream looks the exact same as all the other text on the page. So if we can add like an outline to it or like look or how we treat other links in git lab and like put that there, that would, I think, really help.

C

Yeah yeah, just click over here was outlined uh and, and then hover state was there. So when, as soon as I like go over that because it's a large area I'm bound to hover over at some point and realize that it wants to interact with me. So I think that could do.

A

It it looks so clean though I like that I love the directions. That's awesome, yeah and the other thing to think about uh larissa was I had a question here: performances segments. This is a question, but something to consider like as segments kind of moves along one feed. Some feedback that I heard from dan was that we not.

A

We might not be able to show everything for a newly defined segment, because we need to go and then define a segment, and then we take that segment and then we do like an overnight query to like pull the information from it.

A

So I'd be interested to know what the trade-offs are and if we can like put like either some constraints on segments uh right now to say like oh, a segment could only be like, maybe one group, even or maybe it could be two groups or something so that we can actually show something for that segment as soon as it's created, because what dan was talking about a while back was like oh we'll, create a segment, but then we're going to say you know check in tomorrow and then we'll be able to see.

A

Show you some data on the segment and I don't know if that's going to be a great user experience, so just something to consider dig into their performance, as we kind of like think about that. So we can set some constraints on on that. So it's useful for users.

C

D

I think that's a great suggestion. Thank you. It seems like a good thing to be iterating on and um just restricting it and then incrementally, adding.

A

Yeah and for the mvc, I would say that just having a segment and a segment is one group and you can just like define like a custom label for that group. So you can say, like oh group x, is actually like team y or whatever, and you can see that the team y segment everywhere they can iterate, add more groups to it add more customizability over time. That's what I would suggest, if that's a constraint that you you find yeah.

D

A

All right, we got two minutes left uh harris over to you, bring us home.

C

Okay, I can definitely uh do this in two minutes, because uh I've talked about this a lot and I feel, like uh you know, people are already familiar with what we're trying to get done. uh Our implementation of the group migration. This is not migrating, just the groups, but it's migrating uh groups, subgroups projects, sub-projects everything that belongs to group is pretty much a. uh You know a gitlab instance. Migration. One group at a time um is in progress.

C

uh The nbc has not been delivered in 1306, but our goal for uh for the next milestone is to fully deliver that mvc and enable the feature. So um that is the goal for for for the next milestone. Once the feature is visible, then the users will be able to just do that.

C

One click migration of the entire group with all the subgroups you you know uh using this view here, where you would uh name your group, give it a where you would provide your personal access, token, url and connect to the instance select the group that you want to migrate and then go ahead and import it once this feature is fully delivered.

C

We will follow it up by a set of issues in this epic here to implement some of the non-functional requirements, and this is really important, because one of the reasons why we have set on this particular path is that some of the other attempts and the uh especially the uh file based export and import uh we're not able to satisfy some of the non-functional requirements that we do have for uh for our importers.

C

So the scalability, the resilience, replayability efficiency- like all of these things, that we want to be able to do for the users which are non-functional, we were not able to implement in that. You know using the file based exports imports that we do have. So we will follow up the mvc by going back and putting in uh all of those non-functional functional requirements into uh into the product before we move on to providing more and more features to it. So that is the goal for 13 7..

C

um Do we have five seconds four questions.

A

I think so um no questions come to mind right now. I'm so excited for this feature, because it's gonna help self-manage in and our gitlab.com customers be able to to move uh move to to a platform uh that they that they desire um really excited to see that kind of come to fruition.

A

uh Thank you so much for that um and I think that's that's basically it for uh the 13-7 kickoff for manage. Thank you all so so much for the great work. I'm really excited. Bye, cheers all take care.