 Well, hello everybody and welcome to the GitLab 1111 kickoff meeting. What we'll be talking about some of the features that we're releasing in our upcoming release. This will be the one next month. So what we're going to be doing is going through each of the categories that make up make up the GitLab DevOps stages and talking about the individual features from each of the product managers that are going to be presenting those. So again, my name is Jason Lenny and I'm product manager here. And to start things off, I'll turn it over to Jeremy for Manage. Thanks a lot, Jason. I really appreciate it. So this is I'm Jeremy Watson, product manager for the Manage stage of the DevOps life cycle here at GitLab. So Manage stage is really all about helping enterprises and large instances really prosper with strong configuration. In this release 11.11 we're really focusing in on access control and enabling some of that configuration in order to help instances stay more secure. So here to talk about like four really exciting premium slash silver level features that we're adding in 11.11. The first two are related to LDAP. So what typically large instances will do who are aligned at LDAP is they'll use that as a single source of truth to not only help determine identity but also access control by using LDAP group sync. Well, one issue that we want to solve is that LDAP doesn't allow you to use it as an immutable source of truth. Group owners and group maintainers are still able to add users to the group outside of LDAP sync. In 11.11 we're going to be able to enable locking memberships to LDAP sync and also enabling group owners optionally by from as an option from that's enabled by GitLab administrators to allow group owners to manually add members to that. So LDAP can be a very secure and immutable option for maintaining a single source of truth for your users. In addition, we're also enabling a configurational option to only allow non-adminced archive projects not delete them in GitLab. Deleting actually is deleting and some instances require a data retention policy that only allows or will allow non-admins to actually archive projects and delete them. So we're enabling that more than 11.11. And the last feature that I'm really excited about especially for GitLab.com is allow restricting group members by a domain whitelist. Sometimes you want to make sure that a group in the lab can only be accessed only certain members can be added to it. And in 11.11 you'll actually be able to specify a domain mask to only make sure that certain members who match a email pattern can actually be added to the group. So this is especially useful for groups on GitLab.com when you want to make sure that your membership can be tightly controlled and you're only adding certain members potentially employees of your organization. Now you can do that and make sure that your group stays secure. So that's what's going on in Manage. Jason, back to you. I think some really nice features there that are going to help with managing users. That's for sure. Victor, over to you for plan. Thanks Jason. For plan we're working on a couple of things. We're going to continue pushing in the realm of portfolio management. So Jason if you don't mind click on the first link there view epic tree and epic. That's something we've already started in a previous release in particular 11.10. What we're doing is we're going to be able to see child issues in your current issue or let me correct myself where we're already able to do that as a couple of releases ago. But what we will be shipping in a couple of weeks is the ability to see the roadmap view inside the epic. So if you're an epic and you have children epics you can see the roadmap the Gantt chart as it were of those child epics inside the epic page itself. And for this particular issue we're not only going to be able to see the roadmap page or roadmap bars. You're also going to be able to see the child epics formatted in a tree structure. So similar to you know Windows Explorer or finder on Mac where you can see you know your directory your files in a tree structure you're going to be able to do that here as well. So that's something we're really excited about from a work breakdown structure perspective and something we're really excited about. The next feature I wanted to talk about is scoped labels. That's the second link Jason if you don't mind clicking. We're actually shipping that again in a couple of weeks in 11.10. Last time around we call this a key value label. So scoped labels is the same thing we just renamed it to something that that's a little bit easier to understand. And so what we're shipping in a couple of weeks will be functionality to have mutually exclusive scoped labels. And this issue of what we're going to do is make it a little bit easier to understand by styling it a little bit different. So what you see on the screen there you see DevOps plan DevOps is the scope it's the key as it were and plan is refers to that value. So something we're really excited about we're going to make a couple of other changes to scope labels as well but this one is definitely the highlight for this iteration. And then the last two are things that we've been working on in the past couple of releases. We had some technical underpinnings that we needed to fix. I'm excited that we'll actually be able to ship these very soon. So go ahead and click on them and see those designs at your own time but I wanted to turn it back to Jason. Thanks Victor. That epic tree and epic wine is really cool looking. And I like the way the styles look on the labels. Over to you James. Thanks Jason. If you click through onto the first issue about resolve discussions a few releases ago we introduced the ability to suggest changes to a merge request if and at the moment when you apply it you also have to click resolve discussion to mark the discussion as resolved. And in most instances that is the typical behavior that the user is expecting and would like. So what we'll be doing is removing that second step and making it a one-click action to apply and resolve the discussion with the suggested change. So that should be a really great improvement for people who are adopting that. And we're also in a separate issue hoping to make the feature more visible and easy to find. Thanks Jason. The next item to highlight is around WebID workflows with forking. And you can take a look at the design on that issue. At the moment when you open a you can't open projects that you only have read only access to because you won't be able to commit your changes and we don't want people to make changes and then realize they don't have permissions to commit them. But in 11.11 we'll be adding support for forking workflows in the WebID so you'll be able to open a read only project and then in the commit interface create a fork and commit it to that fork at the same time. Also related to forking we're excited to be getting what we hope to reach general availability for de-duplicated forks. So when you fork a repository we make a full copy of all the data in your fork. And that uses twice the disk space means that creating a fork is relatively slow because we have to copy all the data. And we're hoping in 11.11 to de-duplicate that data. So forking won't necessarily be faster initially but the disk storage requirements will be essentially zero when you first create the fork and only the difference as the fork diverges will be stored. Next up is improvements around LFS. So we've had mirroring features for many years in GitLab and great support for LFS but we didn't support mirroring and LFS together and that creates a bit of a problem for projects that want to use both features either for a project maybe stored in GitHub and they're using GitLab CI or you have multiple GitLab instances and need to mirror the entire project from one location to another. So we'll be adding support for LFS objects. And finally we'll be making our first iteration on group merge requests which is allowing merge requests across different projects to be related together and then enforcing merge order. So making sure that a service that needs to change first doesn't merge after something else that depends on the change. So making sure that that relationship is expressed and that'll really help large monolithic projects with lots of microservices that need to coordinate the order of merging do that efficiently. Thanks Jason, back to you. Thanks James. I love the suggested change workflow in GitLab and it's cool to see that we continue to iterate on it. Brendan over to you from Verify. Great. Yeah thanks Jason. My name is Brendan O'Leary and I'm a product manager for the Verify stage here at GitLab. Verify covers both CI which is continuous integration as well as automated testing such as unit and system testing. Today I want to talk about two issues. As you can see there are more than two issues here but a few of these are left over from our 1110 release including the vault group of concept integration as well as the windows container executor and cross project upstream options. We're really excited to see these as well but if you want to learn more about them check off our kick off video for GitLab 1110 for the details on how those features work. The first issue that's new to 1111 is visual review apps. This will be our first step into a new category usability testing which is part of our 2019 product vision. So this feature will allow users to look at and comment on a review app directly from within that review app. Those comments then become discussions in the associated merge requests. This will help designers, product managers and other stakeholders review the visual and UX changes to an application just as easily as their development leads can review the code changes right in our request. The second issue is about renaming trigger to downstream. Trigger is what lets you decide what project should be built after the current project's pipeline is run and today that's the word we're used for. To go with the upstream triggered by option that we're adding in 1111 will be renaming triggered downstream to kind of avoid confusion about what that exactly means. And so big shout out to our UX research team who helped out with this, helped us to understand kind of with data how to name this feature and make it least confusing for our users and customers and other stakeholders that all contributed to that research. Yeah, so back to you Jason. Great, thanks Brendan. The visual review app item really has a ton of potential. I'm excited to see how that can enable teams who do review workflows using review app. So thank you for that. And then the next two items are mine. So the package team is responsible for repositories for the various kinds of artifacts that you either depend on or build as part of your release process. And we'll be finishing up the group level dependency proxy MVC in this release which we also talked about in the 11.10 kickoff. And then two new things that we're adding are a template to build and push to the MPM registry as well as one for the Maven registry which will show you how easy it is to get this set up and working. One more item that we're also looking at is ensuring that the registry registry garbage collection task deletes all of the blogs that it's supposed to do. We're continuing to focus a lot on making sure that the cleanup and maintenance of the repositories is also easy to do with GitLab. Then for the release category which is all about continuous delivery and the things that support it. One of the most exciting things that we're doing I think in this release is merge trains from merge request pipelines. So what this is going to let you do is queue up a series of merge requests that can all run in sequence and merge in an ordered fashion into master. And there's some optimizations and efficiency hacks that we can do there taking advantage of that pipeline to make sure that everything comes in as quickly as possible without using too many compute resources but also in a way that keeps master green. So I'd encourage you to check out that issue give us feedback on how you see that coming together. It builds on our merge request pipelines feature that's been out for a bit now and we've been continuing to iterate on. And again it's one that I'm super super excited about. Another interesting one here is adding type or extensible environment variables. So what this is is being able to set an environment variable in your project that has a type associated with it and so this may create a file on your file system. It may be a certificate and the benefit of us knowing the type of the variable is that we can do a lot of validation. If you've ever had a situation where you've had an expert space and a certificate and everything is failing and you can't figure out why you don't understand why this validation can be really really powerful. We have a few other items here that are nice but I'd encourage you to take a look at those on your own time if you're interested. They're great features but we'll move on for now. So with that I'll move things over to you Daniel for Configure. Thank you Jason. I'm Daniel I'm the product manager for the Configure stage here at GitLab as we have some exciting things that we're going to work on on 1111. The first item comes from 1110 though and we're just going to get it over the line and that's disabling Kubernetes resource creation. So as you know when you use the Kubernetes integration today we create a namespace and a service account dedicated for that specific project so we want to give users the ability to manage that on their own. That is GitLab will no longer create those resources for you but you will be able to manage those in a more fine-brained manner. Then the second thing that we're going to work on here is the ability to provide separate namespaces for each project as part of the Kubernetes integration. As you know every name space or sorry every environment deploys to the same name space that is created for that project. So let's say if you want to deploy to a different name space for staging versus development this will be now supported with this feature and this will be great because the ability to run different environments and different namespaces allows you to do more things around security and appointments. Then the third thing is that we want to allow users to uninstall the apps that they have deployed through the GitLab Kubernetes integration. So let's say you deploy the runner as part of your GitLab integration but then you want to stand it up in a VM and no longer in your Kubernetes cluster you will be able to uninstall the runner from your Kubernetes cluster. Then we move on to validating the Kubernetes credentials that you provide when you create a cluster. So when you add an existing cluster we ask you for a couple of things such as a certificate, a token, and an API endpoint. So right now we don't validate those so if there was a problem with any of those you wouldn't know until you deploy something or you make news of your cluster so we really want to make sure that the data that is being entered by the user is valid and we let you know that early to minimize problems. Then we move on to instance level cluster configuration. As you know today you can create a cluster at either the project group level with this feature you will be able to create a cluster at the instance level so all of the users for your instance can take advantage of Kubernetes. And then the very last thing is around serverless so that is the ability to use the GitLab serverless features with an existing k-native installation. That is when you bring a cluster that already has k-native installed on it we can't currently make use of the great features that we have around GitLab serverless and so this is all about enabling that if you bring your own cluster that already has k-native and that's it for the configure team back to you Jason. Thanks Daniel some great improvements there over to you Josh for Monagre. Jason I don't think Josh is on right okay let's come back to that Fabio do you mind going that way secure? Yes Jason thank you for that so for secure in 11.11 we are planning to work on a security reports API so we have security reports that will give you the list of vulnerabilities that is affecting your software and this list is used in the GitLab UI to populate the security dashboard of the merge request widget. We started it at the beginning as regular artifact but then we make it more first class and so now they have a specific format and they use a different syntax this will prevent the JSON files created by the security tools to be available as raw artifacts. We know that there is a need to download this information in a machine readable format like Jason because teams I mean the security teams want to automate security on top of these results so with this iteration we'll provide a new API and point that will make available this information again and it will improve it so now you can define multiple jobs that will create multiple reports for the same kind of vulnerability for example SAST. The API will aggregate all of them and will send you a polished version with the exit list you want to take on this API so this is very very important it has been a requirement from customers but also from our internal security team so we're very happy that we can work on it now. We also want to provide an option to enable active scan for this for dynamic application security testing at the moment DAST is out of the box doing passive testing and so it's not fully finding all the possible vulnerabilities that are affecting your application we thought about that we consider different options and we figured out that enabling the active type of scan for DAST is very valuable it will give you more results more information and it will not be so invasive anyway we will not do it by default and we'll allow users to define an environment variable in case they want to switch to the active scan model based on the feedback we'll get on this we'll define if we can have a better default or if we can consider different situations for example we can run active scans on review apps that are disposable and there is no way that can provide they will provide a problem production and the actual passive scan on production only so we make sure that this scan will not impact availability of your website. The third issue we want to work in 11.11 for the secure stage is to add an optional reason when dismissing vulnerabilities we add a very strong feedback from customers and analysts saying that collaboration between security teams and developers is better if security teams know why a vulnerability has been dismissed by a developer so that's the reason why we are considering adding a reason the reason will be optional so it will not create any friction to developers if they don't need if they don't want to go through this path but in case they want to add a note so other people can see it when looking at this miss vulnerability it will be possible and that's all for secure back to you thanks Fabio I love that the collaborative feature there of making sure that the information is flowing back between the teams in a natural way it's a nice one look over to you for fulfillment yeah thanks Jason um so in 11.10 we introduced the ability for users to buy additional CR run-of-minutes this is only added to paid plans so in order to iterate upon that we wanted to add the ability to buy CR run-of-minutes for free plans so that that was a little bit more complex to include in the first iteration so breaking it out and we'll hope to continue on this next one thanks Jason that's fine thank you Eric over to you for distribution geo and then monitor that one as well yep absolutely thanks Jason so postgres 10 brings about a number of performance improvements but namely aggregate pushdown support which would really benefit our geo product and so for distribution we're planning on shipping postgres 10 in the omnibus package alongside postgres 9.6 in 11.11 users will have the ability to manually upgrade postgres 10 fresh githlab installations will still have postgres 9.6 and if you upgrade from 11.10 to 11.11 we're not going to touch your existing postgres version so we're really excited about the performance improvements that postgres 10 will bring about in the future the other interesting thing out of distribution is is we're working on automatically importing an enterprise license on githlab install so this will help on a lot of internal users to essentially apply a license against your githlab installation right after it's right after it's brought up without a manual license application but the primary use case for this is for our marketplace images and so dovetailing into the third item in the list we hope to have a an official supported amazon marketplace image of githlab ultimate supported by 11.11 with a license automatically applied when that am i is deployed to an ec2 instance moving on to geo so i'm also really excited to announce that we're planning on supporting a geo for kubernetes in 11.11 so this is adding support to the githlab helm charts for geo and then moving back up to monitor there's a number of improvements for monitor that we're doing so one of the first things is we're adding new unicorn metrics so we're going to add process stop and start time and also the number of unicorn workers that are being tracked we're replacing the m tail metrics with our native unicorn metric code for stability we are also planning on adding instance metrics type to the usage ping allowing us to get a little bit more information about who's using these these metrics and in githlab instances and then the last thing to to make a note of on monitor is we added monitoring for the integrated githlab registry recently but we didn't yet add the metrics to the omnibus dashboard and so in 11.11 we're planning on adding those metrics into the dashboard and so those are the ones we wanted to highlight from monitor there's a few other ones there take a look please comment on the issue if you have any comments back to you jason thanks so much eric so many great items in this uh in this release it's uh it seems always be the case but i love working for a company where we can touch so much of the dev ops pipeline and deliver so many great things to so many different kinds of people uh every time i'm always blown away as we tend to say best release ever i think this is going to be another one thanks everybody for for watching feel free to reach out to us on the issues we always welcome contribution collaboration and we'll talk to you soon