GitLab 14.9 Release Kickoff, 16 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 14.9 Kickoff - Release

Description

Release 14.9 Planning Issue: https://gitlab.com/gitlab-com/Product/-/issues/3805

A

Hi everyone I'm chris palani the senior product manager for release, I'm here with daniel fusco the senior product designer for release, and this is the release, 14.9 planning issue, so we'll go through the goals and engineering deliverables for the milestone, I'll pass it over to daniel to discuss the design work um I'll also go through the docs work, that's happening and then we'll wrap up from there.

A

Okay, so for the goals for the milestone, uh what we want to do is iterate on the major features that we've been working on. So specifically that's in the environment, page we design and the deployment approval work.

A

The next goal is continuing our work on reliability and the last goal is to continue our work on our instrumentation with the product, okay, so on to the issues um for our release, p1 issues we'll start with um adding the approve or reject comment to our approval feature, and so this is critical for this feature to allow our users to add a comment for the approver rejector, and so the idea is adding being able to add more context as to why they approved or rejected that deployment job, and this is really critical for especially for sort of compliance and auditing for for uh for users and teams to provide that justification for um for this further decision, the next one is continuing our redesigning work of the environments pages that we have so specifically we'll be applying those new design, components to the environment, detail page and so again.

A

What we want to really do is improve the readability and usability of that of that page, and now that we've built all these components, we can we're able to reuse them and apply the new design.

A

The next one is aggregate counts for deployments, and so today we're not quite counting deployments that may not use environments as part of their their yaml file, and so this is continuing work to actually improve the accuracy and make sure we count those deployments. So we better understand how users are deploying using gitlab.

A

And then so. This issue in particular aggregates the counts uh that that we have for um deployment stages as well as deployment jobs.

A

The next one is multiple onstop for an environment, so today there's a limitation in that we only run one of the unstopped hooks that are defined in a in a ciaml file, and so what this issue proposes is to extend that functionality to allow users to find multiple hooks, which may be useful for potentially more complex deployments and kind of tear downs of certain environments, and we want to make sure we can account for all the different sort of branches and complexity that deployment may have.

A

As you can note, this is also a very popular issue, so we want to make sure that we continue to add value for our users and provide functionality that will be useful for their workflows.

A

The next one is group level protected environments, do not support inviting invited groups. So, as you can see, this is created six days ago, but um this is a key limitation that one of our customers, who's uh implementing gitlab ran into, um and I'm excited that we're able to sort of respond quickly and and get this resolved. And so the the sort of the problem is that um at the group level, protected environments, uh weren't supported within by invited groups, we want to add that capability um in this milestone.

A

The next one is separate access model for deployment approval, so uh today what we have, what we built in our mvc um provides the ability to find users that are allowed to do the approval as part of being kind of users in the protected environments.

A

What we want to do is sort of extend that model in terms of having separate groups and users that can do the execution, the ex the executors of the deployments versus users that can do the actual approval, and so this model is very common um in sort of a segregation of duties model where users that actually kind of write the code and deploy are separate from users that actually approve those deployments. And so we want to add functionality into this feature to allow users to be able to find those separate groups for those deployments.

A

The next one is continuing the reliability work for get lab pages, and so specifically, this one is adding rate limits for tls connections.

A

Now that we've completed ip and domain based limiting, we want to add, extend that rate looming capability for tls connect connections in particular, which will help alleviate cp usage and make sure that the features rely continues to be reliable for our users.

A

B

A

Those are our p1 deliverables. We have a few p2 and p3, as you can see here, a few security issues, continuing our instrumentation work and a few of the ux core card wrecks that we can pull in if there's more capacity.

A

With that I'll hand it over to daniel to discuss the design issues.

B

Thanks chris, I'm not sharing my camera because my connection was a little bit unstable, but all right, let's go over the design for 14.99 from the top. You can see our teams uh for this milestone. The main one is actually the second one connecting releases environments and deployments features across gitlab um environment. Adoption here is being tackled from the perspective of fixing usability bugs and improving small small features, small issues across environments to ease adoption of these features. So the first one is the connection between releases and environments.

B

This issue has been proposed a while back and it's still a very generic proposal. uh So the idea on here is to scope out this issue, separate it into smaller ones and then start designing or validating.

B

Whatever is needed to bring these issues closer right so either showing environments and deployments information in the releases page, or vice versa, to help our users uh have more connected workflows um the after that the the the ones the three ones after that with the severity labels, are part of a broader initiative from the ux department to address ux issues that have severe labels. Some of them have been open for quite some time, um so these are usually small issues, but as an aggregate that make a lot of difference on the user experience.

B

uh So I'm happy that we're attacking these as a department and also happy that they align pretty well with the work that we are already doing in release. uh So you can see here the first one um is a small bug with how environments show show themselves that stopped. If one stop fails.

B

Next up, we have scary wording for re-deploying environments, essentially improving the copy around the the buttons to redeploy environments and the third one is a bug with gitlab pages, when you archive your project.

B

The issue with three after these show deployment, drawback and redeploy labels is another improvement to our rollback and redeploy interface that connects with the first one uh with the severity 2.. uh So I'm happy that we'll be tackling this from two different directions: to improve uh how our users can roll back or redeploy their deployments.

B

After that we have uh two other ux issues. One of them is a ux tab that we want to tackle, and the last entry is continuing. The pajamas work that has been started in 14.8 to get our new uis for environments and deployments and make them into components, uh so it's easier to adopt them across gitlab and that's it for design. I handed it back to you, chris.

A

Daniel okay, you'll notice, a new section in our planning issue um and in the spirit of collaboration, we've added a doc section for coordinating and highlighting the technical writing work that our stable counterpart russell will be taking on. In addition to the milestone sort of feature, documentation, that's always ongoing, and so um uh for for those that, for that additional work, we have two line items here. The first is a research spike to clean up the gitlab's pages administration, documentation that we have we've.

A

This is a very popular feature, and so we want to make sure our documentation also is able to answer all the questions that we get from our users and customers and sort of refactor to make it to make sure that it's easy to follow and readable.

A

And then the next one which I'm also really excited about, is documenting how to use semantic release with gitlab. So we actually got a customer call or a customer request about semantic versioning for our releases feature, and today we don't have native support for semantic versioning.

A

uh Yet it's on our roadmap, but in the meantime, um xenia provided uh an approach that uses an open source package, called semantic release and there's already a package out there, there's already a plug-in that users can easily integrate and use with gitlab, and so we thought it is. It would be a great idea to provide just to add that documentation to our pages so that user users are able to to leverage gitlab and this package to get the um the benefit of doing semantic versioning.

A

So um we think this is a great um sort of solution until we can actually build a new adobe and gila and we're going to work on that in this milestone.

A

All right, so that's what we have planned for 14.9, more detail in this planning issue. I need.