 And we're live great. Thanks Victor. Hello everyone. My name is Kenny Johnson I'm the product team here at get lab We are going to be presenting the kickoff call for the 11.10 release This is the release that will come out on April 22nd. So next month a reminder to everyone that we will go through each individual product manager's stages walking through the new features that are in the milestone for this month, but we do plan Ambitiously and so it's not the expectation that every single thing here will get merged and be delivered on April 22nd With that I'm going to hand it off or I'll continue to share But I will ask Jeremy to walk through the issues for the managed stage Yeah, thanks a lot Kenny really appreciate that intro So I'm here to talk about three exciting kind of new additions to the product The first one is a further iteration of what we've been working on for the past couple of releases Which is an enhanced version of group SSO. That's primarily designated towards get lab calm in this release We're adding in new user flows for both users that are using something called Group managed accounts, which are a dedicated user account specifically locked to a particular Enterprise's activity and also you new user flows for SSO enforcement in general So if you're curious about this or an enterprise is interested in these features Some of the sketch prototypes that we have for that flow The other thing we're adding is we're also adding additional support support for STIM Allowing enterprises to actually create users before they actually join your organization So we'll have an endpoint available for for adding users making this a real enterprise great SSO feature The other two things I'm excited to talk about is a simple change is ability to add multiple owners to a project for a long time the assumption in get lab was that a project had one owner and this led to some interesting behaviors when as Companies tried to kind of work around this limitation But we're moving that we're allowing now projects can have multiple owners Which makes a permission management much more flexible for for projects in general and I'm particularly excited about the last item Which is the ability to customize your time zone within get lab for a long time time zones in get lab are locked to GMT and Now we're adding the ability to customize that at the user profile level to select your time zone But also to allow it to select the preference of whether you like to see times in 24 hours versus 24 12 versus 24 hours and also see absolute times rather than relative times throughout the product So particularly excited to see a more flexible time preferences throughout the product and the CSSO continued to Purate and improve but that's all for manage back to you Kenny Awesome, thanks Jeremy and great to see the time zone conversation on the first day after our daylight savings time change here in the States I'll move it on to Victor if you want to cover what's in coming up in the planned stage Thanks Kenny if you click on the first link view epic where relationships in epic. That's the issue that we started Earlier from the last release and we haven't finished it quite yet. So you can see from the screen The third screen there you can see where we're going to show roadmap views We're going to show tree views right inside the epic itself so we're really excited to continue to work on that in this release and Likely ship the tree view first the second issue again is a hangover and that is creating an epic from the epic itself and so that makes it really easy if you are doing a work breakdown structure and you're continuing to scope out work and You just want to create an epic there You don't want to go back to a list of you can just do it right in line there And again, that's something we started last release and we're gonna continue it in this release Key value labels is something brand new and if you don't mind clicking on that Kenny There's there isn't a mock-up per se, but you can see the What the highlighted and read there? That's how we're going to Take advantage of the space of titles. So within the label There's a light label title obviously or the name of the label And so what we're going to do is take advantage of that. So we're having something called key value So the example you see there is if you have the word priority Double colon one that could be the name of one label and another label could be priority colon colon two and the idea is For any given issue merge requests or epic you can only have one of these labels So so like the key is the priority and the value is one two three or four So essentially it will be mutually exclusive and and these labels will be applied with some type of replacement logic And we think it will solve many interesting use cases So do take a look at that one and then the last two issues I wanted to mention really quickly are some additional visual designs things that we've started working on And we're continuing to iterate so issue list row design and related merge requests Design if you want to click on both word quickly Kenny you can see in the issue list of version as you scroll down you can see additional Sorry, not additional. You can see how it's been restyled. You can see in the issue list now. You have you have a header And then you have the labels all together there You can have you can see the title just the different meta information has been grouped in different ways And so designer Pedro worked a lot worked on this a while back and had some really good results I mean speaking with users and doing a little bit of research the related list merge design Related merger quest in issue design is something that we've already released A milestone or two ago and what we're doing in this particular issue is adding additional information So right now if you look at production data You'll see just the title And you'll see the icon on the left and the and the pipeline status on the right, but you won't see things like a signee And another information there and so we're going to add that with this particular issue. All right back to you Kenny Great. Thanks Victor. Yeah, I'm especially excited about the key value labels I think that's a great use of an existing primitive so On to James for covering what's gonna come up in create Thanks Kenny, I've got three new features that are particularly exciting to share with you on the create front The first is adding some new get push options to create a merge request when you push from the command line So it's quite common that you want to be able to just quickly commit to master and particularly for projects that you're a maintainer of and I don't know not your Production application, but maybe some documentation or other things that you want to have really low barriers to contribute But the problem with pushing directly to master is you could break the build and So what we're doing is we're introducing a new get push option to create the MR So that you can set it to merge when pipeline succeed That'll be the second iteration So with one push you can commit create a merge request set it to measure on pipeline succeed And then assuming you haven't broken the build your merge request will merge just like committing directly to master but without the risks The next feature to share with you is multiple discussion threads on merge request if So in a merge request where you're leaving code review feedback At the moment you can only leave one Comment or start one thread of discussion on a sit on a line in a merge request And that's great most of the time because normally there's only one problem with a single line of code But there's lots of situations where they might be Sort of separate considerations being discussed in the single thread and it's hard to track whether each one of those is being resolved so for example, you might have written a regular expression which is Incorrect and broken and doesn't do what you expect and that might be one piece of feedback You leave on the line of code But the second thing might be that this should actually be moved into a helpful function in a different area of the application And so that would be a separate thread that you'd want to discuss Separate to resolving the accuracy of the regular expression And so this will be a really nice improvement particularly batch reviews where you can quickly scroll through and start a new Discussion on a separate topic on a line of code that's already got some existing discussion. That's on a different topic And finally the long-awaited and improvement to merge request, which is multiple assignees Just like issues have multiple assignees because often there's multiple people collaborating on an issue There are also often multiple people collaborating on a merge request For example front-end and back-end engineers UX designers, but also during the code review stage It's typical to assign the reviewers and unassign yourself as the engineer during the review process to indicate that someone else is working on this And you're working on something else instead And for large merge request, there's often multiple reviewers reviewing at the same time So this will be tremendous improvement. It's been very popular in the community and we're looking forward to bring it to get lab And then the last two improvements that we were working on in the previous releases improvements to the way suggested changes works so that you can suggest changes to multiple lines and Improving the web terminal and the web ID so that your changes have been buried into the runner environment So yeah, some great exciting changes coming to create side of get lab Thanks Kenny. Yeah, awesome. Thanks James I know the product management team here is heavy users of the get workflow and I saw a lot of heavy Notting excited about these features coming. So Let's move on to Brendan Brendan. Let's talk about what's coming up new in verify But I'm even more excited for what we have planned and verify this release so first off is going to be a Proof of concept for our vault integration. So there's a lot that we want to do with vault And there's a few epics that you can follow this one this issue links to it and that includes both integrating vault as a first-class Secrets management tool for get lab CI CD and verify stage and then to be used by all the stages after it This is because vault really has kind of won the market in secrets management And so we think that it's a great tool and it has an open source version that a lot of our users use To manage secrets and so this Release will be doing a proof of concept of integrating it with a get lab runner And then we're also looking about how can we integrate it as a first-class citizen within get lab and then also migrate The secrets that get lab uses outside of the verify stage Intervault and maybe use fault as the answer for all secrets within You can find a couple videos just a plug for get lab unfiltered you can find a couple videos of our CEO said and also my team discussing that in more detail On the get lab unfiltered channel Next we're going to add a generic metrics report type This is going to be a really valuable feature I think and one that is a small print primitive that we're going to build a lot of the testing features We'll be bringing directly into get lab this year with it's going to allow Engineering teams to track any metric that they can measure that changes over time With it within the merge request and so we'll add a merge request widget that has this generic metrics feature will implement the open Format for metrics tracing that's similar to the friendiest format and allow you to kind of track anything you want to manage if that's Timing if that's performance if that's memory usage you'll be able to track all that over time and Then the longer way to verify feature To go along with the long way to configure feature is the windows container executor So this is adding a new executor to the get lab runner That's going to allow you to execute windows containers on windows systems And so you can read a lot about that now. There's actually a lot that has shipped In a get lab 11 8 to enable this and then get lab 11 9 will be really excited to To I'm sorry get lab 11 10 will be really excited to show the final Great. Thanks, Brendan. Yeah, I really like the MVC approach to our vault integration and exploration Jason would you like to tell us what's coming up in package? Sure So first up for packages the group level dependency proxy MVC and what we're doing here This is going to be a larger feature that we're working on for some time in the package stage But this is going to be a way to Handle you know retrieving and storing and publishing the artifacts that are part of your Build and delivery pipeline in an easier way we're starting out with a container registry and Starting to implement caching as the first thing that we go after but this is something that we can eventually expand upon to include Security and other rules that you might implement in in higher managing Not just your container registry, but maven and and other dependencies that are better downstream And then I also have the release section next so First up is finishing the combined merge refs for merge request pipelines, which we talked about in the last kickoff We've made some great progress on this issue and are going to be wrapping it up in the 11.10 release The what this feature is if you weren't on the last call is being able to actually generate the combined ref of The source branch that you're working on with the target branch and run the pipeline against that combined ref So this is going to give you even more confidence in what you're actually going to be merging into your target brand Next up is an AWS integration MVC Where we want to make the AWS integration a little bit easier to use by giving you a way to enter into your credentials or other configuration that goes with your AWS Integration and make that available to the pipelines that you run Yeah, that's going to be a great feature for just making that a little bit easier to manage and especially at the group level Next up is a group level environment dashboard which will be similar to the Pipeline dashboard feature that's out recently or coming out soon the what this is is a Environment-based view of what's deployed where so if you're somebody who's looking across all of the environments at your company Maybe a maybe you're a release manager. Maybe you're a tester and you want to see what's deployed where What environments has your change made it through on the path to production? This will be a great dashboard for you to take a look and and see what's going on We're also going to be adding automatic HTTPS read certificate renewal for pages By integrating with let's encrypt. We're going to make it much easier To handle that automatic certificate renewal right now It's a little bit of a pain to handle and this is a very highly requested issue So we're really excited to be delivering this and then last up is feature flag permissions in the last release We're launching auditing for feature flags So you'll be able to see what what has changed and when With somebody adding a feature flag or maybe changing the value in a certain environment And with this permissions You'll then be able to control that only certain people should have access for example to change in your production environment What the feature flag value is? So a bunch of exciting changes for a package and release that we're excited to bring out and back to you Kenny Awesome, thanks Jason. Yeah, I'm especially excited about the AWS integration MVC Daniel we want to talk to us about what's coming in 11.10 for configure Thanks Kenny So the first couple of items that we're going to work on just getting them Over the line that are coming from 11 9 first one of those is the ability to disable auto DevOps at the group level for good Lab comm so that's just giving users more control over auto DevOps The second one is updating the Kubernetes deployments label selector So right now we're using the app label for those those deployments So we want to enhance that so that if you're doing deployments to different environments and so on That's going to show up correctly in places like your your deploy boards Among others next is just in time Kubernetes resource creation So right now if you've used our group level Kubernetes integration You know that we are kind of creating those resources ahead of time specifically namespaces and service accounts But we will realize that not all Projects make make use of this integration. So to make that more efficient. We will create them just in time So when we see that the project is going to make use of the integration We'll go ahead and create those resources and we hope to use this functionality on our upcoming Level for the new disintegration as well Next is showing the function invocation count for Kinect functions if you're using the lab serverless In adding to the scale that we're showing you today We'll also show you the number of times a particular function has been invoked and Then moving on we'll we'll also are Excited to begin work on disabling or giving you more flexibility on the Kubernetes integration So we have this here labeled as disabling namespace service account creation So that is the current behavior for our Kubernetes integration that we're creating and managing those resources for you And we've had a lot of requests of users wanting to do that manage that management themselves So we want to give you flexibility in how you use the previous integration. So another option is going to be you managing those Well, next we'll move to a composable auto DevOps and we're very excited about this one. This is basically us Breaking out all the different stages of auto DevOps into individual templates. So let's say if you have You know a CI process that you've spent a lot of time on and you just want to bring one or two features from auto DevOps You can do so now using the includes functionality of GitLab CI So you can kind of pick and choose which ones you want to use and then personalized personalized rest of your CI Implementation to something that fits your flow. This is a very cool feature. The secure group has actually already started the work In templating all all the features like sas and sas and so on Okay, next we The two next ones are around the serverless feature and the first one is creating Runtimes for GitLab serverless. So here The thought is that we want to bring as much functionality in in-house so we can leverage the power of GitLab CI For everything that has to do with serverless. Two of the things that we're thinking about is Kind of creating and maintaining those runtimes and the second one is creating a CLI That will interact with Knative to make use of all these front times so we're very excited about how serverless is growing and the direction that it's going in and lastly Around executable one books. We're excited to begin working on repo integration through Jupyter Hub So basically as you know within the GitLab Kubernetes integration You can deploy Jupyter Hub and start working on your Jupyter Notebooks So what we're going to do here to to start off is going to be Allowing you to see all the contents of your repo within your Jupyter Notebook And that way you're going to be able to leverage all of the content of your repo in your notebook And then a second step we'll look to working on the other way around where you can version control all the contents of your notebook Into your repo. So we're very excited to work on this and back to you Thanks man. Awesome. Thank you Daniel. Yeah, great to see a lot of continued improvement in our serverless integration And I am also particularly excited about composable auto DevOps Josh why don't you take us through what's coming up in monitor in 11.10? Thanks Kenny So we have a lot of really interesting features coming out this release for the monitor the first one is that we want to implement a Prometheus-competible endpoint within GitLab GitLab has a lot of really interesting features integration With Prometheus for example, we can Transparenly connect to a Prometheus instance through the Kubernetes API Without requiring the Prometheus instance to actually be exposed to the internet This means you can have a GitLab server talk to a Kubernetes cluster Which then can reach behind and talk to the Prometheus instance and pull data and generate some reports and metrics Since Prometheus doesn't have its own authentication. This can be a really nice way to not have thrown extra services or Try and expose your Prometheus server. So there's a lot of value there I mean want to expose this for really two reasons one is that if you are Want to use a different dashboarding tool perhaps Grafana or something else that supports Prometheus and many of them do You can simply reference GitLab as your Prometheus resource and then drive your charts that way And so it's a really easy turnkey way to leverage something like Grafana And still take advantage of that value with the routing that GitLab provides through Kubernetes We also have some Like variable substitution for things like CI environment slugs and things like that are also very interesting Yeah, but we also want to use this for our own internal usage as well Right now we have a single endpoint of the drugs are charts And we require a sort of back-end and front-end collaboration to add new features like time windows And we'd like to get away from that and have the front end really responsible for kind of more of the Generating the queries and understanding the output rather than requiring combined work on both sides And so this will also simplify our lives and our own dashboards to make it easier for ourselves as well And so this is a really great feature which provides a lot of benefits For both sort of the external dashboarding as well as our own internal dashboards as well. So excited for that one We're also doing quite a lot to improve the Git by the instance metrics. What this is really is is Making sure we include additional metrics That inform users of the health of their instance for example currently in GitLab.com We generate some metrics using mTail kind of mTail log parsing. We'll have to get away from that It's hard to ship to customers and so you actually want to build those that instrumentation into GitHub itself And so we're doing that here in this release as well as a couple other things as well To help make sure we expose more metrics relevant metrics to our customers in a really easy and consumable way And so help again just hopefully improve the ability of for customers to more easily run GitLab And they can have more compelling dashboards more useful dashboards as well for them to utilize The next item is that we want to allow users to easily open up issues from Prometheus alerts And so essentially if you set alerts out of using the sort of managed Prometheus instance that we deployed the Kubernetes or if you hook up a web authentication from Prometheus to GitLab We can open up issues for you And they're really neat thing is that will also allow you to specify the template that's in use as well So for example if you wanted to have certain labels attached to those issues like incident or a certain service like I get a leak for example you can do that or you could also of course have certain people at mention would look at emails or Stack notifications and so all that great notification services and Labeling is makes it easy to sort of open these automatically and have notifications go out as per normal workflow for GitLab issues And so exciting ways setting features that it helps sort of build some of that Feedback loop from your operational metrics and your alerts back into the planning cycles And so folks can collaborate within the get the issue as a single source of truth Next up we want to improve our dashboard for the deployed applications So we have a couple iterations here, but we're focusing on the first iteration in this case Which is sort of a common set of selectors to drop down on it's right now We render eight hours of data, but that's not always the best case to show And so we plan to offer a range of sort of pre-slip adoptions or common options for 30 minutes out to a week to make it easier to sort of dive in and Get the desired time to let you want And going forward next iterations will also allow more arbitrary Selection of time periods, but this is a good first iteration to kind of help move the ball forward here for this MVC and The next item we want to do is you want to add Requested resources to cluster metrics what this is that we currently show users the currently consumed resources For a cluster and that's how much CPU of memory that that that the applications within the cluster are consuming I can if you scroll down a little bit there's some charts that can show that the new state you want to do. Thanks And we want to go ahead and do is we also want to add to request his data as well And so you can see the currently consumed how much is requested and then the capacity The key thing here with requested is that essentially if you request resources in Kubernetes It's actually makes them unavailable to be used by anyone else And so what happens is that if you are only using half your cluster But you've over provisioned resources if I requesting them you can actually make your cluster unable to run anything new Even though your usage is only 50% and so it's actually really important to kind of keep an eye on both these values to make sure you're requesting appropriate amounts of resources for the workload that you're actually running That can also help you drive greater efficiency in your cluster as well as your users goes up and you have left sort of Less sort of wasted resources that were reserved, but I actually utilized So it's really really nice features there around the cluster health This will also help us build more of a support for kind of driving some of those cost efficiency recommendations in the future And with that I'll pass it back to Kenny Awesome. Yeah, thanks Josh. I'm really excited about opening issues from Prometheus alerts You're in that does kind of keep the feedback loop going from ops to death Fabio, would you like to walk us through what's coming up insecure? Yeah, Kenny sure. Thank you for that. So first of all, I'm very happy to announce that the secure group Will start working on something in the defense stage that is a very brand new scope That will address more the upside of security. So we don't want to wait for the fan Group to be created and we'll pick the very embassy for this item as part of our Responsibility this is specifically to enable not security web application firewall on cluster ingress controller It means that the ingress that you deploy that you provision to your cluster to the Kubernetes cluster We'll have a web application firewall built in out of the box For this first iteration the web application firewall will not block requests But it will create Warnings and a log file with all the possible violations of rules We are also able to load a predefined set of rules from OWASP to spot out of the box The most important and most critical Trats that are affecting web applications The idea is that Users will be able to access this log information and to take remediation in the future Obviously, we want to iterate on top of it and make it more automated the second item will work on and Now I'm talking about the secure stage specifically is to show desk results So the dynamic application security testing results in the group security dashboard This is the very last Sourcer information that we are still missing in the dashboard So we started with sas to results a few iterations ago and then we continued to iterate on top of it In order to make all the all the possible vulnerabilities available This is very important because the group security dashboard is the place where researchers and the director of security are looking at when they have to prioritize remediation for security problems Then we also want to add the severity level to gymnasium vulnerability Severity level is very important because it allows to have a very quick understanding how How big is the problem that you see in the vulnerability And this is to list but not only also to sort vulnerabilities by severity So if we can provide the very Prices level for the severity We can also allow security professionals to focus on what is most important first So this will be shown in the security dashboard It will be shown in the merge request reports and in any other place Where the severity is supported As an additional thing we wanted to be sure that Multi-mobile module maven projects will be supported by dependency scanning out of the box At the moment the setup is not very simple So we are able to support maven projects, but the multi-mobile paradigm is not Possible to be addressed with the current solution since this is a scenario that is quite common in the java world And we know that this is very important for a lot of people We decide to improve the support for maven and to provide This specific scenario as out of the box with the penalty scanning Uh the last item we want to work on in this release is security scanning for elixir This is a programming language based on our longer Uh virtual machine This is a language that is getting more and more traction We got requests for it. We want to include it out of the box as usual as part of our features And with this last item that's all for the secure stage. So can I back to you? Thanks, Fabio. Josh you want to walk through what the distribution team is going to be working on? Absolutely. I will note. Sorry, Josh to interrupt. We're we're at our official time Which is a sign that we are planning ambitiously and have and have a lot But let's go ahead and go over and make sure we get go through your distribution and fulfillment Yeah, I'll I'll try to be efficient here with distribution We have a lot of exciting features here as well a lot of it As far as kind of the new features working on Is around our our GitLab Helm chart and so we're going to go through and add Kind of really make sure we have more of the complete surface area of the GitLab product supported And so namely a geosupport elastic search as well as addressing an issue with the current charts They're actually the current images and a station mirroring So those are those will be great things to be able to add support for and work in our GitLab Helm charts We're also going to be going through and working to Device and hopefully also update our WM package sunny key So that will be expiring in a couple months here and we want to be able to Start proactively updating our packages now Really as soon as possible so we can prepare for a new key And make sure you just can have as little distortion as possible as we rotate those Last we're also want to add eks to our testing suite for our GitLab Helm chart So right now all we have a whole Wide array of automated testing. However, it's all currently based on gke And we'd like to go through and add additional Cluster types really cluster kind of providers services To that test suite so the next one up we want to do is go ahead and add eks And this way as we make changes to our chart We can make sure that for the differences between some of these services Everything continues to work and work well So we want to go ahead and do that eks as our as our second sort of Cluster service have we had to our automated testing suite and with that I'll pass it back to kennon Cool. Thanks josh luko. We'll walk us through what the fulfillment team is working on Yep, cool. Um, so I'm a fresh face in the product team at GitLab I just moved over from the customer success department So I'm really happy to be here as the product manager for fulfillment I'll speak through this quickly because I know we're out of time I wanted to quickly talk about something that we started work on last month We're hoping to get it done for 11.10 and I'm really excited about this Because it's going to greatly improve the experience for for all of our users on comm previously Well now users have a limited amount of CI run-in minutes based on whichever plan you're using And we're excited to add the ability for GitLab group and namespace owners to buy multiple packs minutes before their included minutes expire Which means that users will be able to continue working if uninterrupted Um, that's all for me. Thanks. Awesome. Thanks luko. It's a great great addition um Great, so I think that is all of the items we had to review for the 11.10 kickoff I will say we tried a new format this time to try to be more efficient And we still ran out of time So that is a signal that we continue to add more and more stuff to GitLab releases And another reminder. I would just say that this is uh, this is just a filter of what we release And so stay tuned for the official release notes on april 22nd Um, I for one am excited about everything from improved git workflows that we're adding to completing some more of the devops lifecycle with the Prometheus alerts turning into issues To composable autodevops. It's kind of the full suite. Super excited I think we are clearly on the path to 11.10 being the best GitLab release ever That's all folks. We'll see you next month for the 11.11 kickoff. Thanks