 in its cloud recording right now. So yeah, welcome to the kickoff for folks that can please help out promote people from attendees to panelists. This is of course the call for the kickoff of 11.0 and I'm gonna start by sharing my screen. Josh at the end is gonna tell us if this is the best release ever. So we'll wait for that. And so in the discussion area, I'm really excited because we're doing a variety of things and on the ultimate end of the front, we're going to really close the loop and make epics really complete and have all the features that you would expect from epics. And if you've been using epics right now, you see that they're very similar in nature to issues of merge requests, but you might be thinking, oh, why can't I do to dos or search for, you know, autocomplete and identify other issues and Malaston and stuff like that in the comments and description. And so we're exactly closing that gap in 11.1. And so we're gonna do that, let me, sorry. So yeah, I'm gonna keep going, sorry for the interruption there. And so we're gonna do that for epics. And one thing to note is that you can already get notifications for epics right now. So people have been enjoying using that feature. That's great, I encourage more people to use epics, but we're gonna add to dos and autocomplete. So in addition to getting the email notifications in your email inbox, you'll get the to dos as well in your to dos menu inside GitLab. We've been pushing hard for Jera support inside GitLab and integrating with Jera because it's a lot of our customers are using Jera and they have a lot of legacy systems with Jera. They enjoy using Jera and we wanna support those users, those customers. There's a great feature inside Jera, the development panel. And we have a great support for that inside GitLab. So in the development panel, you can create a merge request, a branch, and a lot of other features that integrate into the SCM tool, in our case, GitLab. But right now subgroup support is not supported there. So if you have subgroups inside GitLab, the dev panel will not work. And so we're correcting that exactly in 11-1. Some weights and issue board column, this has been a stretch issue in the past and we unfortunately can get to it. So we definitely wanna set as a deliverable and be able to see of all the issues inside a issue board column or a list, you can see right now that there's five issues. There's a count for that. And before those five issues, what is the combined weight of those five issues? You'll be able to see that inside an issue board list once we ship this feature. And what I'm doubly excited about is that in 11-0 in the release that's shipping in a couple of weeks, you're going to have assigning lists as well. So not only will you have assigning lists in 11-0 in 11-1.1, you're going to be able to see for, Victor has, assigning list has five issues assigned to Victor and you're gonna be able to see of those five issues, the combined weight of say 23 is also assigned to Victor. So that's super, super helpful if you're doing any type of project management. And so that's a starter feature because weight is a starter feature. The rest of these features are core features, which are things like filter discussion by comments, by comments, activity and issues in merge request, filter by work in progress merge request, a community member started this and we're wrapping it up. So I'm really excited about that. Showing information and pipeline sections design, we have this feature in GillLab, but as our widget becomes increasingly powerful inside GillLab, we want to improve the design and make this super awesome. So we're going to work on that in this iteration. Similar to usable milestone list pages, again, improved design. And finally, batch commenting, we really wanted to do this for a couple of iterations now and we've been blocked by a significant view refactor that's going to come in also in 11-1 and that's going to improve a lot of performance but very importantly, it's going to unblock us to be able to do a batch commenting. So really excited that we can work on that in 11-1 and ship that and that that's going to be a premium feature. Fabio, tell us more about CI CD and security. Yeah, thank you, Victor. Always a lot of issues for discussion that that's awesome all the time. And I don't think that it's too hard to figure out this is the best release ever, as Joshua said. So let's start with CI CD 11.1. So first of all, we are moving on a very new design for the environments view. We are envisioning this pipeline way to understand environments because you have environments but they are normally related with each other and you want to promote your deployments, for example, from staging to production. In order to do that, it's very helpful that you can know exactly which is the status on staging which is the actual status on production but also which are the differences between staging and production. So you know exactly what you're adding to your production environment as soon as you are promoting it. So this first iteration is adding a tab in the environment view in order to give users the ability to know about their environment in this new approach that we are validating. This will be improved in the future and so you will see information like environment theme. You have links to jump into the real deployment. So a URL you can reach with your browser but we also want to show the merge requests that are in one particular environment but they are not in the next one. So you can exactly spot the differences and you know which are the features that are gonna add in the new one. We are also working with a community contributor that already, thank you for that, to an interactive web terminal for CICD jobs. This is very, very interesting and allows you to jump in the job while the job is being executed by the runner. This is very awesome if you want to debug or if you want to do a post-failure analysis of the environment. Normally you are working with a Kubernetes executor or with a Docker executor. It means that at the end of the job the virtual environment, the disposable environment is trashed away and you have no way to access logs, to access information to perform more analysis. You just have to rely on the output log that you can see in GitHub. But with this new feature you will have an interactive session with the runner and with your job. This has a lot of different implications. It can be used in very different ways and they're very happy that this could be leveraged in the near future by the platform team in the web IDE. So it's something that you want to build. It already has a very specific target but also the generic target is very, very cool. And we are also implementing a way to stop environments manually. In the perfect flow, your environments will always be automatically stopped. For example, when you merge a merge request and the review app will be automatically shut down and cleaned up. But sometimes you just have environments that are not closed, that are not cleaned up and there are wasting resources. They are just showing in the list that creating garbage that you want to void. So we want just to provide a very simple way to click on a button and to trash away your environment that you don't need anymore. And that's it for CICD in 11.1. Let's talk about security products features in 11.1. The first very important thing we want to work on is the security dashboard. This is the first step in our intent to support the security teams and security people as a first-class entity in GearLab. So if you are part of a security team, more than the repository code, you probably want to have a security overview on the project that you are caring about. And this is exactly the place where you want to land. Security dashboard in this first iteration will present you the list of projects that you want to keep under monitoring with a very brief overview of the security status coming from the reports that you can also access in the MergeQuest widget or the pipeline level. From there, obviously you are allowed to jump in specific projects and to see more details if you are interested in. This is also intended to be an option that users can set as their default homepage when they're logging into GearLab. So now you have a few options, mainly for developers. You can have your repository or the list of projects. These kinds of things that are very cool for developers could be not optimal for security folks. They will be able to set the security dashboard as such. Another very cool feature that we want to implement in 11.1 is a second iteration on the license management story. So in 11.0, you are able to see the licenses that are in your project because of dependencies of other tools that you are using inside your project. With this new iteration, you will be able to mark the licenses that you accept as part of your project or that you don't want to allow. This means that if your project is open source and is using a license that you don't want to allow because it breaks the open source idea you have for your project to redistribute it, you can just disallow it, blacklist it, and you will see when you create a merge request adding this new license that you don't want that there is a problem, so you can take action. Also, you can just say, you know, this license is good to me, market at green, and so this license will not be considered as a possible problem in the future because you already allowed it. Then we also continuously add the new functionalities, continuing functionalities, what we already have for container scanning and DEST and SEST, so you can find in the list a few issues that will close the loop with existing features that are not implemented for container scanning and DEST. In this specific case, we are working to show the security reports for container scanning and for DEST at a pipeline level. We already have in the merge request widget, but you want also people to access them at the pipeline level. The last point is about a new support for SEST for Node.js projects. We are still evaluating tools and as usual, we are using the best tools available on the market that are also open source and people will just have to run jobs as usual. They will be automatically detected as Node.js projects and the correct tool will be run and the reports will be available. And that's all for security products and now big announcement from starting from 11.1, but they are still, they're already working. There is a new team in Gillab that is the configuration team that is taking over the job about Kubernetes and out to DevOps. So Daniel, what about your planning? Thank you, Fabio. So we have some exciting additions in the configuration area and we'll start with support for Kubernetes RBAC for GitLab managed apps. So now that RBAC has been made generally available in Kubernetes, we're going to support it and implement it as the default authorization method for cluster security. So we recognize the importance of security in the context of deploying applications to our clusters and we want to ensure that we are securing applications properly. So additionally, RBAC is now enabled by default in platforms such as Google's GKE and Amazon's BKS. So it go further to that as well. So this means that when you create a cluster in the Kubernetes area of GitLab on their operations, RBAC will be enabled by default. And then when you deploy an application via GitLab, say Prometheus or Jupyter Hub, RBAC world creation will be automatically handled based on the Helm chart settings for those apps. So we're very excited to bring RBAC into our Kubernetes integration. Let's see, moving on, the next thing I wanted to talk about is protected environments. So we recognize the importance that operators play in the entire DevOps lifecycle. Deploying applications to a production environment is always a sensitive task, especially highly regulated environments where separation of duties kind of is higher taxed. So we recognize operators as first class citizens at GitLab and to that end, the protected environments feature will allow you to determine which role a user or group will be able to execute a deployment into a given environment. At the same time, users will be able to determine which environments are protected. So kind of the same pattern that we use for protective branches. So from here, kind of from this first point, we want to iterate and continue adding features that will bring more value to operators and basically bring them more value to their day-to-day. And that's all I have for configuration. Jeremy, on to you with platform. Thanks, Daniel. I'll actually take platform first. We've got a number of exciting improvements planned for the platform team. And the first I'd like to share with you is the ability to create a readme when you create a project. This is a really simple straightforward feature, but it's really helpful for the obvious reason normally the first thing you do is create a readme. But there's also a bunch of use cases where being able to do this is incredibly helpful. Some organizations really restrict who's allowed to create a project. And so there's a couple of blessed people who create the project, but then if it's completely empty, there's no default branch, there's no master branch. So nothing can be pushed to the project because by default in those environments, the master branch is protected. So currently they have to push the master branch, put a readme in manually. And so that's a bit of a choke point in these organizations that follow these quite restricted workflows. By adding this checkbox, we solve that usability problem for those organizations and make GitLab better for everyone else who just uses it to create their projects normally. The next set of improvements I'd like to share is to do with the Web IDE. So the Web IDE has been getting better and better every release in 11.0. We've got some really great improvements to allow you to switch between merge requests and view pipeline traces and pipeline statuses. But one improvement that we're gonna be working on 11.1 that's gonna make it even better is the ability to view the merge request description when you open a merge request in the Web IDE. And this is gonna be really useful for those who are using the Web IDE for code reviews because they'll then see the description of what the merge request is doing side by side the code changes. And it'll also help developers who like to use a workflow of opening the merge request before they start developing, write a description of how they're gonna break it down and attack the problem practically, and then use that as sort of a reference document beside the code as they write it. So it's gonna be incredibly useful for those kind of workflows. One thing that's maybe not working so well in the Web IDE right now is that the improvements we made to support file staging and committing has made the committing workflow more complicated. And so we're looking to address a number of usability concerns and pieces of feedback to make the staging workflow cleaner, make sure that there's feedback about the information that needs to be supplied and making sure that it's really easy to commit your changes. We really don't want users getting stuck with changes that they wanna commit but they just don't know how. So we've got two issues linked there and a bunch more UX refinements to really improve that committing workflow and we're really excited to see how that will make a difference. Next up we're working on project exports and storing the project exports in object storage. One of the really great features we have in GitLab is the ability to export the entire project, not just the repository, but all the issues, the merge requests, the snippets, the wiki, everything in your project gets exported in this nice little table that you can use for backup purposes or for migrating your project to another instance. And so the way that feature works is that you request the table to be prepared and then you get an email when it's ready. But during that period while you're waiting and the 24 hours following when the link is ready, that table is being stored on the GitLab's disk, which isn't great if you're trying to run GitLab in a cloud native environment. And if your instance is getting a lot of project exports on a regular basis, it can really consume a lot of storage. So we're adding support so that those tables will be stored in object storage, which will unblock some important parts of the cloud native project that we're working on. And finally, also related to project export. We've been noticing some increased error rates on gitlab.com with project exports and we've got a range of bug reports. And so we're investigating and hoping to resolve a significant number of the most common project export import bugs related to the GitLab project export and continue to improve that feature because it is so useful for so many different workflows. With that, I'll hand over to Andreas to talk about some SSH improvements. Thanks, James. I'm really excited about bringing in more of GitLab into our web ID experience. So looking forward to those changes. So we know from our search information that we have that SSH currently is actually number one of our search terms within our GitLab documentation and has been since quite some time. So apparently, this is not an intuitive thing to do. And because of that, our awesome UX research team actually conducted a great user study to on the one side learn about where our users actually struggle on the topic and actually identify small improvements that just make this configuration easier. So the outcome of this research study you can find in the linked epic. So this is partly documentation related, partly frontend, so small changes, but we plan to ship all of them in the upcoming 11.1 release. So at GitLab, we actually believe that everyone can contribute and people should be able to really push through repository on GitLab with as little as overhead as possible. So I'm really confident although that sounds quite small that this is a big improvement to make this experience and our goal towards that a lot easier. So that's that. Next on platform is Cherun. Thanks a lot, Andreas. It's super great to hear us using UX research in a transparent way to continue to improve things for our users. It's really exciting stuff. And James, super excited to hear more about Web ID can you continue to approve? It's something I use constantly and it's so much fun like when you're watching it, it would slowly iterate and improve over time. So I'd like to talk about the last final two platform rows, both of which I'm really, really excited about. So the second to last row is about making personal access tokens better and more secure. So these tokens are generally used for application or script development when you need external access to the GitLab API as a particular user. However, like when you actually create a new API private token on your user, it grants full access to the API Azure user, including destructive permissions for all the users, groups, and projects. So this makes managing the blast radius of these particular tokens like really, really challenging. And so we'd like to take the first step towards solving this problem by introducing project level scoping for personal access tokens 11.1. So when you create a new token at 11.1, you'll actually be able to restrict full API access to a particular project. This is great for groups and organizations in GitLab with hundreds and hundreds of projects where it just doesn't make sense for one really super powerful token to have read, write permissions for every project on the instance, especially for more secure industries and environments. So this is just a start and we'll do more and more scoping in the future. And our goal is really to make sure that you're granting just the right amount of access to these tokens as makes sense for your user, your organization. So I'm super excited for this. This is a problem I'm really excited to solve. And lastly, we're really designing the contribution analytics page. So we've actually got some really cool analytics features in GitLab and this is definitely one of them. At the starter level and above, we actually give you groups and analytics page that helps you visualize pushes, merge requests and issue activity over a period of time. So you can see like who you're in that particular group is contributing the most frequently. And we've redesigned this page actually to be able to better support presenting many, many contributors made the page much more visually attractive and useful. So we've actually got lots planned for analytics in GitLab. It's a big area of opportunity for us that we really see helping users manage their instance activity kind of at a glance. So please stay tuned for that, lots more planned, but I'll leave it there for now. And Andreas, I'll hand it back to you for more for Geo. Thanks, Jeremy. Awesome improvements there. So talking to you, we typically, as always, are continuously working on improving the experience and performance within the Geo team. Two things I really want to highlight for the 11.1 release, starting with the first one, which is actually quite a big one, with 11.0. So the release that is upcoming next few weeks, we actually ship automatic redirects. So on GitFetch and GitPush writes, you actually get automatic proxies to primary Geo instances. So super cool addition that we have for HTTP with SSH following in one of the next releases. Unfortunately, in the upcoming release, redirects do not support Git LFS. And this is actually due to a bug on the Git LFS side of things. And what we're going to do in the 11.1 release is actually going to add support for HDBT repests on LFS. So what we did for that, and that's ongoing, we actually collaborate with the Git LFS maintainers at GitHub. So two weeks ago, we filed a issue on their side of things. And within no time, they not only analyzed and fixed that, but also already shipped the release that actually contains these improvements. So that's really awesome to see. And the second part is a small UI improvement that I actually think makes a lot of sense. So whenever you navigate on the GitLab UI of secondary Geo nodes, you just get the information that this instance is read only and a small link that forwards you to the primary GitLab instance. While this is helpful, it does not really forward you to the actual page where you're currently on. So what we want to do is just put in links that forward you to the direct page, similar to where you are looking at currently on the secondary, which is read only to see the same information where you actually are allowed to add and edit information on the primary Geo node that is related to your secondary. So small change, but I think it helps a lot with working on Geo scenarios within our GitLab UI. And with that, I'm happy to hand over to Josh with monitoring. Yep. Thanks Andreas. That's all really exciting stuff. Can't wait for the Geo improvements and of course all the platform features as well. It's all really exciting. On the monitoring side, we have some similar setting features. We just missed delivering our SLI alerts in 11.0. And so we'll go ahead and be finishing it up and get it out the door here in 11.1. This is a great way for users to easily go ahead and add alerts to any machine they have, whether it's ones that we automatically detect or also alerts that users have added themselves. Maybe it's a business metric they want to care about, like cart sizes and things like that. It doesn't matter, you can set alerts on error rates and things like that and get those delivered to you in email. So that'll be a really great way to close a loop and get notifications with the monitoring service that we have here in GitLab. We're also building on top of another feature that we delivered in 11.0, which will be coming soon, is we added the operations tab. And right now there is the environments and the Kubernetes workflows within that tab. And we're gonna go ahead and build on top of that start with 11.1 with the addition of metrics and also logging options. And so we're really building on a great home for all the operations-related features and having all these things promoted from in the case of metrics being underneath environments and logs being attached to deploy boards and really moving those frontends that are making them easier to access and also increasing discoverability and usability of these features. So really setting features there as well. And there's a couple of kind of associated issues to do a couple of things to the workflows to make that work and make that sensible. We're also gonna go ahead and try to deliver on the first iteration of our trace integration with Yeager. And so this is again, just the very, very beginning where we'll add the option to essentially proxy through to Yeager in a cluster with the GitLab authentication applied since Yeager itself has not provided authentication and could potentially contain some sensitive information. And then also again, render the UI in a new tab. And so essentially you would see a tracing option in that operations drop down there or sidebar, clicking on it, what again, just seamlessly take you through to Yeager. But again, we'd be in the proxying for you in the authentication for you to make it easy to interact with where it might not be if it's again, resulting in the Kubernetes cluster and you're on your PC at home, for example. So some very exciting features there for monitoring. We also have some really important features coming for the distribution team as well. And one of what we've been talking about for a number of releases here is that we're really making some great progress on the cloud native Helm chart. This is a really great way to deploy GitLab on Kubernetes and the various variants of Kubernetes whether it's EKS or GKE or Vanilla. And we've gone ahead and again, made a new chart and we've also split out the containers into five major services. And this will make it easier to scale them. They could easier to make them redundant. And also critically, we've removed the need for NFS. And so this way they're easier to scale and run and operate in a highly available fashion on Kubernetes without some of the kind of perhaps not very cloud-friendly official requirements like NFS. And so again, that's just some of the highlights there. We're gonna be in beta here at 11.0 and we're on a journey to going to GA here with 11.1 coming up. So again, some very exciting progress there and give them a try. It's really great way to deploy GitLab. We're also making improvements onto the Raspberry Pi packages. So right now, this is actually a pretty popular way to deploy GitLab from smaller instances. And right now, we have just the packages but unfortunately, Justi is really kind of no longer available easily for the Raspberry systems. If you go like nubes, for example, or Raspbian, you're gonna see stretch. And so you wanna make sure the package available for stretch to make it easy to go ahead and install GitLab on Raspberry Pi. Since again, this is a fairly popular to go ahead and run GitLab. So we're working on that here on that one. And certainly we're also doing some internal work here also for folks who are perhaps using source to improve the build caching and package bit of times for compiling packages. Right now it can take like 30 minutes and we've estimated the cost for ourselves at like a one or two euros. And that can be problematic for the developer workflow. It reduces how often, you know, you can iterate as a developer if you wanna get a package and try it out. And also of course, having some costs attached to it, they got harder for us to have this enabled by default automatically and more pipelines. And so by being able to improve this up, but hopefully allow developers to have more access to packages, more quickly test their features and also again, allow us to unlock additional package buildings, additional workflows. For example, right now it's a manual option in the pipelines for GitLab CE and GitLab EE pipelines. So that's the same work we have here for distribution as well. I think, you know, overall, again, 11.0 is a pretty setting release. It's a major release. And I think most people thought we had a really hard time topping that one, but with all the amazing features here in 11.1, from the core features with some key UX improvements, we have, you know, that amazing pipeline view in CE, that grid improvements, the web ID, I use it all the time. I love it. And it's just getting better and better. And of course, also we got the RBAC features coming in for Kubernetes, which would be huge. And then of course we have in the premium side, Batch comments, which is amazing by itself. I know my email box has a fill up rapidly and when someone's doing review, it's a lot of the fantastic to have. And then of course, on the ultimate side, some really great features here with alerting, the security dashboard, security enhancements, and all of a sudden together, this is an amazing release across all the tiers. And we can't wait for this to be available. And I think of course, it really is gonna be the best release of GitLab ever. So thanks everyone for attending. And we look forward to seeing you on the next release.