 Hey Brandon, morning. Can everyone see this okay? Yep. Perfect. Yes, I think there's a mode, Luca. Where the. Everyone's cursor goes away. I remember how you get to that. That's not it. Isn't it just full screen. I think there's, you actually have to add something to the URL. Hold on. Oh, really? Okay. Yeah. I'll send you the link. It's the view for web. That's what I just did. You did view for a web. Yeah. Although I think I just broke it. Yeah. Click the, click the link. I just said it's like slash pub. The public. I just sent you the link in the thread on the product channel. Thanks. Can you, can anyone hear me? Yes. Hey James. Can you hear me all right? Yep. Okay. I can finally hear you. I was in here before. I wasn't working at all. You're good. I'll be right back to you. All right. Happy Monday, folks. Welcome to get labs release. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Get labs. Welcome to get labs release kickoff to 12.1. My name is Luca Williams and I'm the product manager for get labs fulfillment group. I will be your emcee for today's call. For those of you having attended one of these before over the next 30 minutes, each product manager will talk about some of the highlights and exciting features of this stage. to our first speaker, Virginia, I want to remind folks that we do plan ambitiously at GetLab, so please bear in mind that it's possible that some of these issues may not ship in time for 12.1, which will be released on July 22nd. Over to you, Virginia. Thank you. Thank you, Luka. So I'm Virginia and I'm the Senior Product Manager for Measure, which is one of our groups. As we mentioned during our last gig of call, we are doubling down on our efforts to create an analytical framework focused on improving the transparency and efficiency across the development lifecycle. In many organizations, engineering and product teams span multiple groups and projects, while most of our analytics, unfortunately, have been on the project level, which makes it very difficult to get a sense of where the majority of engineering and product manager effort is spent. We've definitely heard your feedback, and while our final goal is to move all analytics to a top level organizational level, in the spirit of our incremental approach to building and focused on velocity, we're creating a group level engineering productivity dashboard and moving some of our improvements to psychoanalytics to a group level. While our vision for psychoanalytics includes work on vaster management mapping and customizable workflows and stages, working off some of the group level visualization work and trend analysis with the existing stages that we have already defined. We will enable filtering per project, date range, and we're applicable milestone or alter. And the third issue that we have here is productivity analytics. We believe that by deep diving into productivity analytics, the engineering will basically allow engineering managers to understand how well they're deploying resources and spot patterns across individuals and projects. Productivity can slow down for many reasons ranging from degrading code base to positive things like quickly growing themes. And we're true to start the journey on how to best convey important, problematic, or exemplary patterns across individuals and teams. The first version will be an MVC and we will involve mainly histograms and trends focused on the time to complete an MR, but we have a very long way ahead of us. Because of that, we ask you to please comment and provide us any feedback is welcome. Thank you very much. Thanks Virginia. Who doesn't love data, huh? Over to Eric for plan. Yeah, thanks, Luke. I appreciate that. So for plan, we've got a number of improvements coming to both boards and epics. So the first two issues there are obviously targeted at boards. One of the things that you can't do today in a board is collapse a list in a board, which means if you have probably four or five boards at once, you can't see the end of the board view, which is typically the closed column, which means it's really difficult to drag issues from say a column or a list on the left-hand side all the way to the closed column for boards. And so what we're going to do is provide an ability to collapse a board list, which should let you one drag issues farther over to the right on a board, but also will let you visually indicate which lists are most important in a given board. So super excited about that. And then in addition to improvements on collapsing lists, we're also going to let our users move multiple issues at the same time amongst board lists. This is a really painful thing to do right now in boards. If you've used them for any amount of time, it's difficult to, if you have say 10 issues that all need to be moved from one list to another at the same time, get to do that individually. We want to make group actions a better experience inside of boards. And so we'll be doing that by allowing you to do a multi-select for moving issues amongst board lists. We also have a number of epic improvements coming, primarily starting with inheriting epic due dates. So one of the things we didn't do when we released child epics a few months back was allow the children to give their due dates to their parents. And so in this release, parent epics will inherit their children epics due dates, which will allow for much better project management all the way down to the issue level. And then there's two other things that we're going to allow from epics this release, which is creating an issue from an epic and then creating a child epic from an epic, which will allow for top-down planning. Oftentimes, at least I know when I get an idea in my head, our customers have also validated this, you start with an epic and then you think of all the tasks that you need to add to that epic. And right now that's a very disparate and confusing disorganizing experience in GitLab where you have to go make a bunch of issues and then you have to kind of make sure that you have the issue links up in other tabs and then you copy and paste those and you add those as related things into an issue or in an epic. And what we're going to do here is we're going to let you very easily make and create a top-down plan starting with an epic, adding a child epic if you want, but then absolutely going into issues so you can step out an entire project very easily. Luca, over to you for fulfillment. Thanks Eric. Some really exciting stuff happening in plan where it looks things. So for fulfillment, we're making some further iterations on notifications for our CI runner minutes add-on purchases. So we are currently working on trying to implement how users can be notified in various different ways once they're about to hit their quota limit, which is going to help big time when people are running lots of pipelines and constantly hitting those limits. We want to be able to let people know in good time. And then the second one is self-service upgrades for GitLab.com users. Up until now, we have not had the ability for users to upgrade their GitLab.com plan by themselves. They have to reach out to a GitLab team member, so I'm really excited to announce that we're going to be able to do this pretty soon. Over to James for Create. Thank you Luca. The first item to draw your attention to for the source code group in the Create stage of the DevOps lifecycle is the ability to specify merge order across projects. So this is very important for large projects that are split up into multiple sub-projects. This is particularly common if you've migrated a monolithic application that was maybe stored in a Perfos Depot or something like that and you've migrated it to GitLab and there's dependencies between the different projects and being able to specify the merge order allows you to coordinate the merge process between the different projects and make sure that you don't break the build in the process of doing that. So we're hopeful that the first iteration will ship in 12.1. The next issue is with regards to providing a streamlined approach for resolving confidential issues through a confidential merge request and the way we're doing this is using a fork that's private and so resolving confidential issues in a confidential way is really important for open source projects. It's critical when a security vulnerability is reported that in the process of fixing it and resolving the issue that you don't leak the issue itself. Sometimes it can take quite a while to find the right fix and make sure that it's fully tested and mitigated and so using a private fork there's going to be a streamlined confidential merge request workflow and finally a frequently requested and really great improvement to code owners is coming. Currently you can specify lists of people that are responsible for different areas of your code base but you'll also now be able to specify groups and when you use a code owner's file you can see the ownership when you browse the repository and it also automatically assigns and requires approval depending on your configuration for merge requests when using a code owner's file. Kai over to you. Thanks James. So for the editor group inside of the create stage we're going to continue working on live preview in the web IDE in 12.1 so we've got a lot of exciting things here happening with being able to mirror changes that happen in the web IDE. I'll put those to the terminal and render that in real time which should make editing and working on projects and doing tests that much better inside of the web IDE so we're continuing the work on that. In the knowledge group of the create stage we're continuing the work on design management so we're shipping a very small mvc in 12.0 that allows users to upload designs and along with that we now are going to continue iterating and adding comments and discussions to those items and then the other thing that we're bringing into the knowledge stage is the previous version so as these discussions happen and changes are made it's very important that those conversations continue to happen and we are able to compare the changes that happened on previous versions to the new versions to make sure the right changes are being made as those designs continue to move along. So on to Brendan for the verifying. Great thanks Kai. So there's two issues that we're really delighted to be bringing with verify this time around. The first is generic executor for the GitLab Runner. This is something that's going to be an extremely powerful primitive that we're hoping to use for a couple of known use cases but we also think is going to expand the use cases for GitLab CI and the Runner in general. What this will allow folks to do is to prepare and modify the environment prior to the running of the runner. This will allow people that have maybe hardware or licensed software that we might not have access to as maintainers of the GitLab Runner project to expand GitLab Runner and use it in those environments. So use cases such as high performance computing virtualization tools that we don't use or own here at GitLab. This will open up the ability for users to use the GitLab Runner much easier and more effectively in those environments. Second is group level required CI jobs for requiring and include at the group level. So in GitLab 12.0 we brought the ability to require jobs at the instance level. This will allow folks to have an auditable trail of a job that runs on every pipeline but bringing it to the group level makes it more flexible for our self-managed users and also enables our GitLab.com SaaS users to use this feature. So we're really thrilled to be bringing that in 12.0. Thanks, Brendan. Over to Tim for Package. Thanks, Luca. There's two features which I'm really excited to share for our upcoming milestone. The first is add support for CC++ developers to build, deploy, and publish their packages to our package registry on GitLab. So if you're a CRC++ developer and you start using this MVC I'd love to hear from you and get more feedback how we can make that feature more useful in the future. And the second is we're starting to improve our NPM integration. We've heard a lot of feedback about users having problems with it, not being able to use it from subgroups. So this issue will enable organizations that are taking advantage of groups and subgroups to be able to publish and deploy NPM packages. So hopefully this helps a lot of people unblock or unblocks a lot of people from using this feature. That's it for me, Karina. Awesome, Tim. Thank you. Over to Karina for release. Thank you. Yes, in release stage we are excited to bring forward a few new capabilities starting with the parallel execution strategy of merge trains. If some of you remember from our last release, this is the next iteration of our merge trains MVC. In the last release the MVC was first focused on the sequential train of MRs, meaning one at a time. In this release we are moving towards a more efficient target method in managing trains that will allow sequenced MRs to run in parallel pipelines with initial working assumption that all will pass to maximize the pipeline type. To ensure we're now allowing a failed change in the train we will maintain an orderly delivery to the target branch by not allowing the failed items and previous in the train to merge. Instead a new train calculation order will occur, which will recognize the first non-failing item as now the first in the train, cancelling the failure point in its previous train. This is the great next step to what we were really working towards. The previous MVC of the sequential was really just a starting point and now this is landing us in an exciting addition to drive efficiency in our pipelines at scale and something we're excited to bring in this upcoming release. Another item that we're excited to bring forth, which is a stage of our progressive delivery, is the user ID based access for feature flags. So this is a great addition in the fact that we will allow today you have feature flags that you can turn on and turn off. Another important step of that is being able to manage the users who have the ability to see and experience those features. So what we'll allow is user IDs through an API called Enleash that will allow you to add your users. They don't have to be GitLab users the way that it's executed to be enabled for that feature in that environment and this will allow for very targeted testing and potentially for progressive delivery and future canary releases. So that's pretty exciting. Also we have the pre-release status for releases. So today, not just for our users but also our GitLab team, we would like you know we most likely the ability to start defining a release and making it visible before it's truly ready to be to be committed and so what we're going to do is we're going to add the ability to create a draft release and tag that so that similar to how we do roadmaps we're able to start to formulate our draft releases versus a fully committed release and then real quickly a modification enhancement that had a lot of user community feedback was making the delete an environment capability available in the UI. So basically you had to do that via the API on delete environment but now we're adding this into our user interface where you can delete that environment right next to the stop button of the environment. So really exciting release for us moving forward in the release stage of some key things for our strategy. So we're excited. Thank you. Back to you Luca. Thank you. So we actually don't have anyone to cover for secure today unfortunately so we're going to skip over that and go straight to configure. Daniel. Thank you Luca. So I we're excited to begin work on bringing Knative at the group and instance level for your Kubernetes cluster. So this means that you will be able to deploy those apps that scale themselves up and down to zero at the clusters that you have installed at either group or instance level. Additionally we have a couple of improvements for auto DevOps. More specifically the first one is around not running auto DevOps when there is no Docker file or matching build pack for your project. So as you know auto DevOps relies on a Herokuish to kind of know how to build your app and that makes use of build packs that come kind of in a limited set of languages. So if your project does not fit one of those languages or you don't have a Docker file auto DevOps will not try to build it so that will not result in failed pipeline. And then the second one is that auto DevOps will not run when there's not a runner that can be used for your project. So currently if there is no runner allocated for any kind of build you kind of will just see a hanging build. So we'll remove that so to let you know that there's no runner that can take care of this build. Then the next couple of improvements are for the Kubernetes integration. As you know currently you have the ability to uninstall the runner helm chart when it's deployed from the GitLab managed apps page. So we will provide kind of the same capability for both the Jupyter Hub and Ingress. The next one is that we will be removing the ability to create a non RBAC cluster in the cluster creation with GCP. Basically Google Cloud has they have deprecated non RBAC clusters. So basically RBAC clusters are now deprecated. So we want to remove that capability in the front end so you get the most secure cluster possible. And then the last one it's a security improvement for the deployment of KDEA which will allow the use of GVisor. GVisor is a technology that sandboxes your containers so they don't have access to one another so could they run in a more secure way and prevent you know any kind of security threat where if someone breaks out of the container it would have access to the neighboring containers. So we will implement the use of the security feature. And that is all for the KDEA team back to you. Thank you Luca. Thank you. Over to Sarah for monitoring. Thank you Luca. My name's Sarah Wildner and I am a product manager for monitoring team. So I've got two main themes for what we're going to be working on this month. The first two issues have to do with enriching issues with content and different actions. So this will be the first wave of enrichment that we're doing. We will be adding the ability for users to link and then embed metrics visualizations directly in an issue. So this is going to be focused on our incident management product category instead of having to navigate away from the incident in question during a firefight if you're working with a team to resolve an outage. You're going to have access to those metrics directly within the issue showing you exactly what happened and how you might resolve that. You also have access to navigate to the metrics dashboard for a bigger picture vision of what's going on. And the second one, both vital to our incident management and the shoot for 2019, but also useful across all of our stages, those that depend upon issues for workflows, is the ability to embed Zoom calls directly in an issue. So this is going to look like a user generates a Zoom link and embeds it in the description of the issue and we will identify that and service a button at the top of the issue providing people an easy way to hop into a call or collaborate with other people without having to dig for or use other methods of communication to seek out the call that's ongoing. And the last one along our theme of self monitoring is we're going to be adding a default project within new self-managed instances of GitLab so that administrators of our customers and also administrators of our support team are able to see insights into the health of our customer's GitLab instance. In order to surface this experience in a native way, similar to how we would interact with an application that they've deployed to GitLab, we're going to be adding a default project to all GitLab instances specifically for visualizing and configuring the monitoring of that GitLab instance. So this will eventually extend creating instances when your GitLab instance is behaving incorrectly but as an MVC when people stand up a new instance of GitLab there will be a self-monitoring project both for them to have insights into their instances health and also for us to be able to better support our customers. Thank you and on to Eric for distribution. Thank you sir. I'm happy to cover the distribution team this month as well. The first issue is a holdover from the last release. The distribution team is going to be very much focused on continuing to work on supporting Geo for Helm charts and so this is a this is obviously something we've had in the backlog for a long time. We've been working on it for a few months. There's a few more things to finish up in 12.1 and then hopefully in the 12.1 release Geo will be fully supported in our Helm charts. The second issue for distribution is in line with our general strategy for GitLab to play really really nicely with OpenShift and so one of the the limitations of the OpenShift router is that it only allows traffic over port 80 in 4.4.3 which is HTTP and HTTPS. So one of the things that we're looking into is how to accept to get traffic over SSH using the OpenShift router or at least surfacing it in deployments that are using OpenShift and so we'll be spiking into this and either updating our documentation on workarounds or finding a first-class native way to to go and fix this particular issue with the OpenShift router. I also have the next group and I wanted to just quickly let us set and introduce the group. This is the first time that the memory team has has been referenced in the in the release call here or the kickoff call part of me and I wanted to just highlight what the team is responsible for. It's a new team that we've bootstrapped and this team is responsible for reducing the memory footprint of the GitLab application and ensuring that we are responsible and we are giving good stewards of the resources that our customers are essentially giving us as we give them our software and so we want we want GitLab to be a lightweight application that runs well on a variety of hardware platforms, variety of clouds, even some more kind of abstract and off-the-wall deployments like Raspberry Pis. We want to make sure that the the code that we're writing is as efficient as possible with respect to performance and some of the the resources that servers and CPUs and systems are giving us and so we formed a memory team to tackle those problems and I'm really really excited to highlight two themes that the team is focused on in 12.1. The first theme is we want to ensure that we are using the right technologies in our application. Our web server currently is Unicorn and there's a concurrent web server out there for Ruby called Puma. Puma is actually part of GitLab. It's included in GitLab but the support is experimental right now. However enabling Puma should allow us to reduce the memory required by the GitLab application significantly as it can handle more than one web request at a time unlike Unicorn and so we've been working on this for a while. This issue is slated for 12.1 and so we're going to enable Puma by default which should really help with the memory consumption of the application. The second issue is also really important and it's aimed at getting better visibility into the memory uses during our internal development cycle. We have a hard time answering some questions such as when we add new code how much memory are we adding to the boot of the GitLab application? How much memory does adding a new Ruby gem add to the memory requirements? How much memory allocation during application initialization is required to run the components that we're developing? We want to be able to answer these questions more responsibly and more efficiently in order to do that we need to get some more metrics and so the second issue the gather derailed benchmark results as part of metrics is doing just that. It's allowing us to be more self-aware about what we're measuring. It's allowing us to get better metrics with respect to memory and then of course feeding that data back into our development team so that we can be more responsible when we develop new features with respect to our memory requirements. So really excited that this team is now bootstrapped and that we're making progress and excited to see what comes out of that. Luca that's it for memory. Awesome thanks Eric. Cool so I'm loving some of the creative focus stuff that's happening over in Kaiskamp and create some super cool analytics and metrics functionality coming in measure and monitor and lots of exciting and long-awaited improvements in plan and verify. Really cool stuff it really is the best release ever I think. Since we had a skip secure in geo today I'd like to encourage you all to go check out those issues. Thank you all for your time looking forward to this stuff coming out. Take care everyone.