 Cool, we are now live We'll get this started in about three minutes It's now a midday here on the east coast so we'll start up start the kickoff for 11.3 which in all probability is going to be the best release ever We're live streaming on YouTube So please ask your questions in the in the chat and we'll try to answer them and keep an eye on them as we go Victor is on vacation, so I will be presenting the plan features for 11.3 So I'll just share my screen So I can give you a taste of what is to come and here we go All right so first up we have a wonderful improvement to Quick actions for issues So we have this this great feature called quick actions that makes it easy to apply labels update milestones and assign people to issues and merge requests you can now assign an Issue to an epic using the new epic and remove epic quick action So this this improvement will be really useful for me and anyone else who makes use of epics So that you can more efficiently manage How issues and ethics work together? Next up we have some more improvements to milestones and ethics and how they work together When you add lots of issues to an epic often they'll be part of multiple milestones and you want to see When that epic is going to be completed so if I've got one One issue that's going to be done at the end of this month and the second phase is going to be done the following month It'll be really great if the epic could automatically detect the end date For these issues based on the milestones assigned and coming in 11.3 is going to be This new option in the epic to select whether you want to fix the end date for your epic Or whether you want to automatically derive it from the milestones on the issues So this is going to be a really great improvement and it'll reflect into the roadmap for you And for those who aren't familiar with the roadmap view it looks something like this So the end dates and start dates Once this feature ships will automatically adapt to this change So these three features that I've just shared relate to epics, which is an ultimate feature So they'll be shipping in the ultimate edition of GitLab Next up is batch comments on merge requests So this is a feature we've been working on for quite a while and I'm very excited about And it makes code reviews much easier because you'll be able to leave multiple comments and then submit them in a batch So this way if you're reviewing a large set of changes You might come across something that doesn't make sense and you start to add a comment But then a couple of lines down you you read a few other things and all of a sudden the comment a few lines above Doesn't make sense the question's been answered by reading further through the merge request So this makes it easy to not add the comment That's irrelevant and also I guess review all your comments before you submit them So they're more cohesive and make more sense And so this is a screenshot of what it's going to look like There's going to be a new start review button and you'll also be able to continue to add a comment immediately as is already supported So this will be a great feature as coming to premium edition I think on yes premium edition And finally we've got some great improvements coming to the merge request list row design so When you're viewing lists of merge requests There's a lot of really important information that it'd be nice to have in the list view That's a little bit hard to read sometimes And so there's been a lot of work to redesign how these issue lists are going to look and so they're going to look a little bit like this with a better label view More clearly visible milestones and estimates and assignees and checks This is going to be a really great improvement for people who work in merge requests every single day So that's it from the plan team Jason Can you share it with us what you're going to be working on with release and verify? Hey Jason just jumping in since I know you just joined You can share your screen by mousing over the hangouts and looking for the green Screen share button in the upper left-hand corner. You should be able to share your screen that way Fabio, maybe we should move to you and then we can maybe come back to Jason Just a little bit. Absolutely, Jari. Thank you So I'm gonna share my screen and Okay, I want to Share with you what is new for the secure team in 11.3 secure team is the new name of the security products team That's the same people same awesome features. That's the new name to adopt to the DevOps life cycle This month we want to release a very good improvement That is showing the security testing results on the environment page If you look at my screen that you can see These pictures that are preliminary mock-ups not not the final version, but just to give an idea of that in the operations environment View we want to put something related to security and in specific We want to add a badge for each environment So for each deployment that is there in the list that to show to users if security checks We're good or not for that specific version it may seem a very small thing, but it is very important trust me because when you are An operations person or a security team person you are not into the code all the time So you probably are more familiar and you go every day in this specific page And so in just one single view and one single look you can have an overall idea of the security of all your Deployments so different environments for example your staging environment or your production environment And this is very important because from here clicking on the badge. You can jump to the very specific report You can see in case of some red flag what the flag was for and so what is affecting Your production environment for example and from the report then you can start the process to create a fix and To make it land into production as soon as possible So this feature is very very important and we want to support as gila the product wants to support Not just developers, but also security teams and operations teams. So this is a Thing that is going in that specific direction Okay, so that's what's new in 11.3 for secure. It is an Ultimate feature it is an ultimate feature. So it will be an ultimate tier and Now I am very very interested to hear if Jason is able to share something about the very final release Otherwise Daniel Jason are you there? I think we're still dealing with some technical problems on Jason's end So I think we'll we'll go to Daniel All right Thanks, Jeremy. Let me go ahead and share my screen Okay So Thank you, Jeremy. Thank you Fabio. So let's chat about what the configuration team is going to be working on The first feature of the configuration team will work on is protected environments So this is a feature that we worked on this past release, but we didn't quite make it to the finish line So we will work to ship this in 11.3. So protected environments provides the ability to as the name implies protect an environment So that the ability to deploy is limited to certain groups or users So this is important as insensitive or highly regulated environments There is oftentimes a clear separation of duties that requires the ability to limit who can deploy to environments Let's say such as a production environment So this feature will be the first of many to support operators and make them first-class citizens in good lab Okay, let's move on to the next one and the next feature that I want to chat about is support Kubernetes RBAC for GitLab managed apps So currently when you deploy apps to your Kubernetes cluster We are forcing a back which is attribute-based access control and with the release of Kubernetes 1.8 RBAC has been made generally available and Because it provides powerful tools to limit authorization permissions within a cluster It is the preferred way to Authenticate so we want to make sure that we provide the most secure and modern way for our users to manage authentication in their Kubernetes cluster So with this feature every app that you deploy to your cluster From GitLab, we'll use RBAC by default Okay, let's see finally the last three features that I'll be talking about are related So I'll talk about them as group and they have to do with enabling autodevops by default So back in 11.0 Autodevops became generally available no longer in beta And as you know, autodevops has not only auto build, but it has things like auto test Auto code quality sast dependency scanning License management container scanning review apps dast auto deploy browser performance testing and auto monitoring it has this great number of very cool features and we want as many Of our users as possible to take advantage of the great features autodevops has to offer and that are built right into GitLab So to that end we will be turning autodevops on by default for both Our hosted users on gitlab.com and our self-managed on-prem customers So at the same time, let me see this is GitLab.com At the same time, we are aware that autodevops may not work with your current setup For example, if you're using the language for which there's no build pack Or if you don't have perhaps an image of your container or things like that and to address that the last feature That I want to talk about in this group is automatically disabling autodevops upon first pipeline failure So if your first autodevops pipeline fails, we will automatically disable autodevops for that project Now we are working towards covering as many use cases as we can So when we do ship new autodevops features, you can simply re-enable autodevops for that project So you can take advantage of all these awesome features that we have for you And that'll do it for the configuration team. Let's see Jason, are you with us by chance? Thanks a million Daniel. I think we might go to Fabio I think Jason is still having a few technical issues. So Fabio, do you think you might be able to speak to Jason's item? Yes, absolutely So I'm gonna share my screen again So for the verify and release team, that is the new name Will be the new name for the CI CD scope for people that just joined We are gonna work in 11.3 in a very cool feature Actually, it is improvement to an existing feature that is they include the keyword that you can use in your gilab CI YAML files This allows you to get external files for example HTTP based files or other files in the same repo and Include them as part of the definition of the job that is composing your pipeline In this way, you can reuse definitions you can fetch things from the outside and this is very important and very powerful With the current implementation, we have some limitations and so Each single file should be a valid YAML file on its own This implies that you cannot import a template for example a YAML template Because there is no way for the linter to validate the file one by one because for example The main file that is including the template that is referencing a template that is not known to the linter And so the linter will fail and will give you a stop With the new approach that we are addressing now This will be possible so the linter will be smarter and it will be able to understand the full File the full final logic of your pipeline definition not just file by file This will allow you for example to use YAML templates That's very very important because this can allow you to define a sort of external library of functions that you want to To to use and you can also share this library publicly with the community and the community can contribute And so this is really awesome and we want to support this kind of flow So this is the goal The technical part will be probably not so Impacting users so users will continue to use include keyword as usual and that's awesome because it will be backward Compatible, but they can benefit of these new powerful functionalities For this iteration that this feature will be gilab starter because the actual include the feature is gilab starter, but maybe in the future it could be worth to Consider if you want to change our idea and to move it to core There is an open discussion that has been going for for a long time So everyone is that is very very Suggested to collaborate and to show which are the best cases for this feature announcement and I think that's all for CI CD. Oh, sorry for verify and release So back to you, Jeremy Thanks a lot, Bobby. Oh, let me share my screen here briefly All right, you should be able to share my to see my screen So there's only so as PM a managed there's only one item that I want to talk talk to and I'll hand over to Andreas Who's been working hard on two other issues that are that are in this category? The issue that I want to talk about is linking existing accounts to credentials when signing in by OAuth And this is a you know, we currently support OAuth Authentication in git lab and you can use and use git lab with a number of on-the-off providers like Google for instance But a lot is is is a really great tool to use for managing user credentials But there's one caveat and that is that you're unable to Users that already exist on an instance who tried to sign in using OAuth Currently see an error when they try to when they tried to sign in using the new provider And what we want to do is we want to make switching providers and also adding OAuth providers to existing git lab Instances really really easy and simple So what this is what this issue does is if users already exist on a git lab instance when we tried when they try to often using OAuth they They just simply we just simply link their accounts. So this makes Either transitioning OAuth providers and adding OAuth to an existing git lab instance really really easy And maintainable for the for for users and admins so for these other two items That around group settings and group level project templates I'm actually going to turn it over to Andreas who's been working really hard on these and leading these initiatives Andreas over to you Thanks a lot Jeremy So as mentioned continuing with manage I want to kick off and the upcoming 11.3 released by highlighting two really cool features that improve the usability of our Settings pages on the one hand and working with large project structures on the other side So starting with the settings pages. So in previous releases, we already improved The usability of our settings across the applications So we have project settings which can be quite complex group settings Which are a bit shorter and the admin area for git lab admins and One enhancement we did is moving all these settings into individual sections So these are now expandable and collapsible depending on what you're looking for One downside of that was that you at least don't take one click more if you Want to navigate to the settings and you're looking for of course if you know what you are actually looking for So our extreme idea that we have here is that we want to analyze Which settings are actually the most relevant and most frequently visited by our users So we can actually expose them immediately when clicking on the settings page. So showing here this is basically the High-level UX paradigm. I would say we want to achieve. So we typically show large settings sections Still as is but the most relevant settings should be exposed immediately. So the content Is immediately available to users. So we are starting with group settings and this iteration Basically just because it's our shorting settings page and it's very obvious What are the most relevant settings while for projects and the admin area? We have upcoming UX research that will help us figuring out and nailing what are the really relevant and most frequently visited settings So we can expose those immediately So navigating to a visual design that Matei created here This will be for the group settings The settings page you see when you navigate on that page So the restructure while doing that a couple of those sections and for the groups most important Are our general settings and for the naming but also the group visibility So that will be the settings sections that you as immediately available when navigating there As said the same as planned for projects in the admin area and this will be upcoming Subsequent milestones. So it's not too far away to improve that it was as well. And this is a core feature So next up I group level project templates. So on 11.2 Which is coming up in August 22nd. So this month We are having a first iteration for instance level project templates. So this allows administrators basically to Define an arbitrary group on the instance that has the source of all project templates That will be available to your users throughout your installation and in this next Iteration which is especially relevant not only for kid lap.com a very large instance of kid lap, obviously But also other very project and group heavy structures will be group level project templates So besides being able to define a group that serves as template source on the instance level You will also be able to select a subgroup In any group setting in the future. So those Templates that are displayed in this group are then available on a group level to make it a bit more specific Can see the visual designs here. So that would be on the actual create project page The differentiation you can already see that there's a tap when you navigate to create from template that separates our built-in templates that we are shippings and quite some time already instance level templates and the new group level templates So that really allows you to set up template structures depending on your specific needs in your group in addition There's a small visual design So this is the corresponding idea how to set up those group templates in the group settings There will be a new section that allows you to just select any subgroup of the current group you on and which will serve As the source of those templates That's it for manage. So next up is change again this time with create Thanks, Andreas. I am so excited for project templates. I will quickly share my screen again And I have templates to talk about as well, but file templates So we have a great feature in GitLab at the moment which allows you to create files in a repository and based on Templates that get lab ships out of the box. So common Docker files get ignore files we've got some great CI YAML templates and Licenses for all the common permissive licenses So there's a lot of organizations that might want to use these Like these templates in all their projects But maybe a slightly customized version and at the moment to do that every time they create a new project They have to update the template manually And this is an error-prone and repetitive process So it's a really exciting feature that we're bringing in 11.3 to premium the ability to select a repository Anywhere on your instance and make that the instance level template repository and that will provide a range of custom templates And so these all appear in the the file template drop-down As usual and you'll have your instance specific templates as well as your the general ones that get lab ships out of box So this is a very exciting improvement And we hope to improve it in coming releases with support for group-level template repositories Which will also be incredibly useful for more specific templates And we also want to bring these file templates to the web ID The web ID is a great way to edit and get started on a project and we want to implement support for them here So we'll be adding drop-down so that you can quickly select template and apply it to the file So this is going to be a really great improvement as we continue to improve templating capabilities in GitLab And this will be coming to community edition Next up I'd like to share with you about some really exciting work that's happening around codoners Codoners is a really clever file format that allows you to describe Who who is the person who's really which people are most interested in these files? and making sure that they are always included in review and it uses the git attributes file format where you specify a pattern and a user or multiple users and so a Star would be any file So if you just changed any file user one would automatically be a codon for that but more specific rules take precedence So you can specify specific directories and who's interested in those and even specific file pattern Sorry file types or combinations of directories and file types, there's all sorts of options and In the first iteration we'll be integrating this into the blob view So when you view a file in GitLab, you'll see who the codoners are in future we're going to roll this out to merge requests and Suggest the relevant approvers and automatically assign them even but this is our first step We take an iterative approach at GitLab And so this is the first way we're bringing codoners into GitLab And I think it's going to be really great and this will be in GitLab starter another improvement coming to Approvals and merge requests is the ability to enable self approval of merge requests at the project level. So often Well, the way it works currently is that it sort of assumes that if you create a merge request that you approve It implicitly that's not always the case. It might be a release branch rather than a feature branch And you've just automatically accumulated a bunch of commits and you haven't actually reviewed them yet You plan to do that in the merge request or someone else adds a change to the merge request that you didn't author so there could be multiple people contributing to the one branch and so Assuming that the author of the merge request approves it doesn't necessarily hold true so we're going to be adding this option and Making some changes to the way we calculate the number of approvals and this is a really exciting change for teams that need this feature next up we're we're going to give wikis a bit bit of attention and Improve the way we handle file uploads into wikis at the moment If you upload images or attachments to a wiki they get stored in the uploads directory which is outside of the repository and This is a bit of a problem if you try and check out your wiki Locally and try and render it because the images aren't in the repository So you don't have access to them. You can't preview them You'll just have dead links and similarly if you want to clone your wiki repository onto a different server It's also incomplete. So we really want to improve this and we're going to do that by adding support to the the web editor for wikis so that it'll automatically upload the Attachment or the sorry the image or file into the uploads directory inside the repository and in an upcoming iteration We'll also be adding support for LFS because if you're uploading images Those are binary assets and they probably begin to belong best in LFS for performance reasons So this will be really great for customers who make heavy use of wikis and this is of course in community edition and Finally a really exciting milestone coming in 11.3 is giddily version 1.0 We've been working on giddily for a long long time and it removes our dependency on NFS and the 1.0 milestone is about Migrating all of our git operations that we use for the gitlab.com instance into giddily And turning on all the optional feature flags so that there'll be no more direct access to the NFS storage For git repositories on gitlab.com So this is really huge for gitlab.com It's also really huge for self-hosted customers because it means that giddily is getting very complete and in 1.1 which we'll be coming at very shortly will be removing large amounts of all the The old gift code inside of the Ruby application and everyone will be using giddily for all git operations. So huge congratulations to the team for this milestone and Fingers crossed it it all goes to plan and you can read more about the the giddily project at gitlab.com gitlab.org slash giddily and learn a bit more about I guess the architecture of this important part of how gitlab works I'll show who's next Josh you're up Thanks, James. That's all really exciting I can't wait for giddily 1.0 and all the future enhancements to come there now that we have that as a base They go ahead and share my screen here and We can talk about all the amazing things coming to monitoring so hopefully that's coming through And so we got a couple items here for monitoring to discuss. One of them is that This release or the lease as that is now just about to ship 11.2 We included a new learning feature SLI alerts for any kind of custom metrics that you have so for example if you're trying to keep track of say How much Checkouts you have our carts or credit card processing numbers and you wanted to have some alerts in case You know say your credit card processing errors exceed a certain percentage You can get those alerts now set them in gitlab easily and receive email notifications in case any of those trips We've now also working to add that to our kind of out-of-the-box default metrics that we also provide for people This is very common metrics like throughput to response rate a latency with the engine x ingress services also things like CPU memory consumption through Kubernetes pod resources and so you can now be able to set Alerts on these kind of again out-of-the-box alerts as well not just ones that you set yourself as well So super exciting there to kind of round out our learning feature We're also making further improvements to the user experience as well So this is the user experience you see today for adding an alert and we'll be adding this of course to also things like again engine Next ingress But we also want to go ahead a step further and for all of our alerts now Show the thresholds on the screen and so for example if you wanted to have an alert configured for say 0.5 percent of the Traffic having an error you can go through and set this here and you'll see the actual bar on the screen Where that is and what that alert was set to and so some nice kind of feedback there to understand What it was for tripping? Kind of how far above you are the threshold and just get some more visual feedback though So that's all very exciting there on the alerting side We're also working to improve just on the general UX fixes a couple things here and there on in particular with a canary charts that perhaps can come and go and can be just some a couple Unesirable UX scenarios in those cases. So we're getting those cleaned up in this release as well Which is also very exciting. So great things to come there on the monitoring side in particular with alerts We're also working on a couple items here for distribution as well. We've got our past release One big item here is that we're going GA with our helmet chart and so we're kind of heads down right now and making sure we deliver that later this month and Later next kind of our next release here for next month. We'll be working on handling feedback supporting our customers who are using it and then some improvements on the way that we have noted They're in the issue list That's come our general list of improvements But you can see those and we've been working to get those as well as any items again that we find as we approach release here So very very excited about that. Definitely give it a try. It's a great way to deploy GitLab on Kubernetes And GitLab in general. It's just amazing itself on Kubernetes. So can't wait to get that out and make that GA We're also making it easier to Confirm and get an idea of what open source components that we use here at GitLab We currently package this actually a file along with all our packages, right? So in every download a package at GitLab, you already have the list available in that package itself But to make it easier to consume easier to access We're gonna go ahead and make that available online to download and to view And it automatically be updated as well. So that would be very nice to have that maintained For some of our customers who were interested in that without coming and surfing to the packages so Clearly this is the best release ever we've actually managed to go longer than the half an hour even a lot It's so apologies for that but clearly couldn't fit all the amazing things that are in this release into half an hour I can't wait for things like our back for convince applications and auto devops. That's gonna be amazing The coder's file and the multiple includes in particular the improved parsing is also amazing I know I've run into that couple times when to have job templates and one file and pulling into different CI file So can't wait for that. I personally as soon as it's out will start to give an edge of it Again batch comments of premium project templates instance templates amazing things there enhancements the web ID for templates in general And of course also things like ultimate with ethics that you cannot tie to milestones and still update dates anymore It's also super amazing. And so I can't wait for that We use those of course here at GitLab and that'll make I think all the PMs lives here is much better So this is amazing release can't wait to have it shipped here next month And thanks for watching and we hope you as excited as we are. Thanks everyone. Thanks everyone Thanks for watching. We'll see you next time