 Hello and welcome, everyone. Thanks for joining us today. We're excited to have you on. During today's webcast, we'll be going over our latest release, 11.3, where we have lots of exciting new features. My name is Agnes and I work on the marketing programs team here at GitLab. I'm joining you from Sunny San Jose, California today. Also joining us this morning is our presenter, Brandi, from marketing. Daniel Grisso and Joshua Lambert from our product team and Chen Jay from our support team. We're going to give people just a couple more minutes to get locked on. While we're waiting, I'm going to launch a poll you can take part in if you'd like. The graphic on this slide may be useful as you think through your answer for the first poll question. Thank you to everyone who participated in the poll. Before we get started, I'm going to cover a couple of housekeeping items. First, feel free to ask questions throughout the presentation. You can use the Q&A function at the bottom of your screen for that. We'll have dedicated time for questions at the end of the presentation and demo, but you can go ahead and send in your questions as you think of them and we'll make sure to get to them at the end. If you are experiencing any technical difficulties, you can use the chat function to get in touch with a moderator, me for help. Now I'm going to turn it over to Brandi to talk about the results. All right, helps if I unmute myself. Agnes, as you can see GitLab is more than just an issue board, source code management and CI, which are the areas that we were focused on in the past. Over the last year, GitLab has moved towards being a single application for the entire DevOps slice cycle. So let's take a look at the results. It seems like we have it right between create and manage, which is great. Some people are also using to release package verify. So it's a good kind of mix, it seems. One of the areas that GitLab has invested in this year is around the capabilities for auto DevOps. So I just want to take a minute to discuss what auto DevOps is, oops, sorry. Auto DevOps is a subset of the phases that we saw in the previous slide. And rightfully so, the seven phases shown here are the ones that can be automated within the pipeline itself. GitLab auto DevOps eliminates the complexities of automating software delivery. It will automatically set up your pipeline and necessary integrations. Auto DevOps simplifies and accelerates delivery with a complete delivery pipeline out of the box. Simply commit code and we do the rest. Auto DevOps detects the language of the code, automatically builds tests and measures code quality, scans the security and licensing issues, packages things up, sets up instruments for monitoring, and deploys the application. So basically you create and auto DevOps does the rest. Now let's talk about the latest and greatest. What are the new GitLab 11.3 features? Our main theme this month was around compliance, specifically features that help automate controls around environments and code while providing further efficiencies for Java developers. For relevant sake, let's pause here and take a poll to see how many of you are currently using Maven repositories. Well, everyone has a chance to vote. There's two things to note. As always, if you need further details on this release, you can find it at the link at the bottom. And we are proud to say that this is our 87th consecutive monthly release. So 60% of you are using Maven repositories. 40% are not. So basically if you know a Java developer who might be interested, you can pass along the information that you get from the next bit. And the rest of you, well, this will be interesting for you. In this release, we have expanded our support for Java projects and developers by building Maven repositories directly into GitLab. And staying true with our GitLab values around MVC, minimum viable change, you can expect more functionality in upcoming releases. Daniel and Joshua will be demoing these features for you today, so I won't spoil their big reveal. I will just say that this really helps GitLab to provide Java developers with a secure standardized way to share version control in Maven libraries and save time by reusing these libraries across their projects. As organizations move toward more automated practices across their SDLC and increasing their velocity of delivery, compliant standards and assurance of separation of duties becomes a very obvious area where automation can ensure governance standards are being met. With our new protected environments features, operators can now set permissions to determine who can deploy the code to production environments. This significantly reduces the risk of the wrong person committing something that they shouldn't and increases overall security of the environment. I'm sure you can all understand why that's important. Very similar to our new protected environments feature, we now support the assignment of code owners to files to indicate the appropriate team members responsible for the code. Again, in GitLab's MVC, by adding these definitions now, it prepares us for future releases that will enforce internal controls at the code level. The last 11.3 highlight is around our project and portfolio management capabilities, specifically around Epic forecasting with integrated milestones. If you're using our PPM capabilities, you know that you have always been able to establish plan start and end dates at the Epic level. With 11.3, you will be able to gain insights into potential slippage and Epic delivery by analyzing the work that is scheduled through milestones. You will be able to understand the Delta difference between when you thought you could deliver the Epic versus when the milestone work is scheduled to deliver. This will enable faster, better decisions on what can be delivered and when the plans need to be adjusted. I'd like to highlight very quickly some noteworthy enhancements, some of which will be included in our demo. Remember early in the presentation when we discussed auto DevOps. In this release, we have enabled that use of auto DevOps pipeline by default. So please look at how that works in the system. Additionally, we have included interactive web terminals for Shell and Kubernetes runners. This is a pretty technical feature and Daniel and Joshua will highlight this in the demo. Also, if you're using our web IDE, which by the way, I absolutely love, you'll be happy to hear that we are supporting five file templates in the web ID that you can take advantage of. And lastly, 11.3 now has SAS support for Groovy. But I've talked enough. Let's see what's new in the demo. Joshua, over to you. Thanks. So let me go ahead and share my screen and we can take a bit of a deeper look at our new Maven repository features that are now in GitLab 11.3. All right, so hopefully everyone can see my screen. If not, please do let us know by posting an item in our chat. But we'll go ahead and talk a little bit about what we have here and what we're looking at. So first off, this is a project in our examples repository. This is a repository that includes a number of examples and we'll be able to build it over time. We have another examples project repository as well where users can go ahead and essentially find some getting started or some hello world type tutorials that they can use to essentially better leverage our features and get a quick start. So in here we have our Maven example and this one comes with a pretty simple Java project here as well as some of the Maven settings and files you might need to configure it. So let's go ahead and take a look at what's in this repository. Again, so we have our pretty simple Maven or Java application here, very straightforward. Again, complexity application itself isn't the goal but the integration with how to publish to our packages service is. We also have the, again, the required Maven configuration files and so here is our settings in XML and you can see here we're authenticating with the CI job token. That is the job token that gets provisioned for every single job, it's unique to every single job, automatically when the CI runs and our Maven repository could automatically understand that and authenticate it securely. The greeting with the job token again is it rotates every job, it's how to secure and if it gets essentially lost or misplaced or somehow leaked, again, it's only valid for that single job's lifetime which typically is just a few minutes. We also have our pond at XML as well and then here you can see that we're defining a couple items here on dependencies. We're also gonna go ahead and leverage our API endpoint for Maven here. So it's essentially the projects URL and you can see here we have parameterized the project ID so it's really easy to reuse this with other repositories and you can see we have packages and then Maven as far as the rest of the URL here. Down below we've again utilized our variables as well to configure the repository URL to get repository, our project URL and also again the get repository URL as well and so you can see here essentially all of the required configuration and settings have already been configured for us simply by leveraging the environment variables that GitLab already generates automatically for you as part of your project and so essentially from here what I can do is I can simply fork this. I'll use my private name space here and since all the configuration, all the settings are all again available with default CI options, we can simply go ahead and actually run the pipeline to go ahead and deploy our first Maven package to my project's Maven repository. So let's go ahead and take a look at this now. We have our packages UI and this is where you'll see the Maven projects show up here. Maven packages rather and we're also working to improve the screen here as well. We mentioned kind of the minimal NVC and iterating towards a larger or more fully featured Maven support which we're absolutely doing and what I was trying to get to here soon is improving this kind of screen here so folks know what's there and know what's happening and how to use it. Let's go ahead and publish our first package. We'll create a pipeline for our master pipeline and we'll leverage one of the shared runners that are available on gitlab.com and you can see here we're gonna go ahead and pull down the standard Maven image to run this particular CI job. That'll take just a few moments to get pulled down by the runner and then we'll go ahead and execute our CI script inside. While we're doing that we can go ahead and take a quick look at the CI script itself. So you can see here just how simple it is. We're gonna go ahead and take that CI settings to XML and copy it into the place that Maven expects it. If you wanted to you could also pass a CLI option to tell Maven where to use a file instead of looking in this directory but in the case that you might have an existing pipeline already set up it can be easier to just copy the new one there. But you can see here again how small and minimal of a required CI script is really required to utilize this feature. Let's go back to our job here. You can see we've actually already started so let's zip back up the top of our job here and we can take a look at what happened. All right, so you can see we did download the image that's great when we went ahead and we copied the settings of XML over to the place that Maven expects it and the user's M2 SAS settings directory. And you can now see we're gonna go ahead and download the required upstream plugins. As you can see we're picking up some Maven items. We're also gonna pick up Plexus as well. So you can see here some plugins are picking up and that's gonna go ahead and download a few of these here based on the requirements. And we're doubting them and then we'll go ahead and once we're done picking these up we'll go ahead and actually start to package things and then post them back up here. So we can zip down to the bottom. You can see we're just wrapping up picking up Plexus here and down below you can see we're now gonna go ahead and actually upload our package to our Maven endpoint. You can see that right here. So you can see you're posting our snapshot and you can see down below we've finished posting the relevant details if we go back to our packages UI. You'll now see we have a brand new 1.5 snapshot version which was configured in our files there. And you can see we've got our metadata and our Pondlin.jar files. So that's really how easy it is to go ahead and get started with Maven integration. Again, the advantage of this being integrated within GitLab is that it's really easy to use. There's not a lot of setup required. You can see here we just basically just forked our example repository and we're able to go ahead and get started. And so hopefully it's easy to use for everyone out there who wants to use it. I'll watch all the developers on this call here. If not, if you have feedback and other improvements you can make, please do let us know. Create an issue and we'd love to engage with you and learn how to improve this and make it better. So with that, I think we can wrap up the quick demo there of Maven and pushing a package to Maven. I can hand it off to Daniel to go ahead and talk about protected environments. Thank you, Josh. Okay, let me go ahead and show my screen here. Okay. Hopefully here you would be able to see my screen. Please let me know if not. Let me go ahead and move this out of the way. Okay, so as you know, GitLab is made so that everyone can collaborate in getting the software value delivered to customers. This effort, operators are every bit as important as developers. So we've been paying extra attention to that side of the partnership to make sure that their needs are met as well. So basically we want operators to be first class citizens in GitLab. And that's the reason we added protected environments. It's important to be able to lock down environments like production to make sure that any changes are well controlled. So just because a developer writes code, it doesn't necessarily mean that every org wants broad access to make changes to the production environment whenever they want. So in fact, many IT organizations are required to keep separation of duty so that the people writing the code are not the same people pushing out the code into production. So when an environment is set to be protected, then the only approved users, groups, or roles are going to be able to execute deployments into this environment. Okay, so one second here. I'm going to share my second screen with my browser just to quickly go over the demo for protected environments. And here is my pipeline screen. Okay, great. All right, so here we see a simple three stage CI setup where the deployment to production has been configured as a manual step. So currently I'm logged in as admin. So let's go ahead and switch over to developer view. And that way I'll show kind of what the developer is seeing here. So here in developer view, I kind of have the same setup. Here you see, I can see the deployment button for this particular CI run. So now let me show you how easy it is to set an environment to be protected. So here when I'm logged in as admin, I simply go to the project settings and under CI CD, I can expand the protected environments section. And here what we're going to do is on the first dropdown, I can select which environment I want to protect. Let's go ahead and choose a production environment to be protected. And on the second dropdown, I can define who will be able to deploy to that environment. So I can choose here for three options. So the first one is roles. You want everybody with a particular role to be able to deploy. The second one is groups. And the last one is users. So basically which specific users are able to deploy. So this last one is specifically functional where if you have a certain group of operators that you want to be able to deploy, but then you want to add one extra person that may be a one of, you can do that through the users here. All right, so let's go ahead and set up the administrator to be able to deploy for this particular environment. Now we'll go ahead and click protect. Okay, so here I'm going to go ahead and go back to my pipeline. Now that this environment is protected, I see that the pipeline is blocked because of that manual step to deploy. And now let's go ahead and switch back to my developer view. And now that the environment is protected and only the admin is able to deploy. Go ahead and refresh the screen. You will see that the action to deploy is no longer available to the developer. So for this particular role that we're logged in as a developer. Likewise here, if the deployment action was said to be automated, and so not a manual step, then your job would fail. And it would basically tell you that the environment is job is the point to is protected. And that basically does it for the protected environments demo. We look forward to operators getting great value from this feature. And we'll look forward to your feedback. And with that, I'll turn it back to you, Raddy. Thank you so much. I think now that's it for our highlights. So why don't we do some Q&A? All right, we have not seen any questions come in. But of course, feel free to continue submitting. But while we're waiting, perhaps the audience be interested in some questions that we've seen often come up. So for example, maybe, you know, Chen Jie, you can answer this or Daniel or Josh. First of all, can we protect that environment or just production? So with protected environments, any environment that you'd have defined for your CI, CD pipeline can be protected. As you saw in the demo, Daniel went and selected production, but there was an option to select staging as well. So any environment that's defined for your pipeline can be protected. Thank you, Chen Jie. I think we've also seen something that we've also seen come in quite often. As far as questions goes, people are often interested in finding out kind of Maven repository stored to S3. So perhaps you'd like to share. Okay. Yes, this is possible to use object storage for this. And I'll post the link to the documentation for this with the steps that one would need to take to get it to work with S3 storage. So I'll just put that in the chat for everyone to see. Thank you, Josh. Still we don't have any questions yet, so it's quiet and drip this morning. I guess if there's no questions, I will basically wrap up with the final question that we often see come up, which is, does the Maven repository support proxy? Yeah, I can take this one. So we actually do want to have the support within GitLab. We do hear quite a bit from our users that they would like to have a solution where they can have essentially a single point on their network that can act as sort of both the network gateway to access these internal or internet-based resources, but also to act as essentially a what-isting agent so they can control essentially what artifacts and upstream resources can be utilized. So we're absolutely looking to build this in, but with this being our first iteration, it's not there just yet. So we do have an issue open for this along with a broader set of improvements to our product. And again, definitely please pass this feedback. Please let us know what you'd love to see. That helps us to ensure we're doing the right things. And of course, an example of this is the proxy support, which we don't have today, but definitely are trying to get in there pretty soon here. All right, thanks again, Josh. And if since we don't have any questions, I think we will move on to perhaps, Brandy, you can share our product vision. Of course. Our head of product here at GitLab has recently given a presentation on our product vision for 2019 and beyond. I would really encourage you to take some time to read his blog or view the recording of our own map and where we plan to go. You've seen in the first slide that I presented how far we've come since we've started to now where we're getting into auto DevOps. So it's kind of, we're growing, we're changing and where we are becoming the one single application for all of DevOps. And on that note, I would like to thank you so much for your time today and back over to you Agnes to close things up for us. Thank you, Brandy. We'd love to hear your thoughts on today's webinar. So please fill out our webinar survey, which I'll drop in the chat. And also we'd like to invite you to sign up for a free trial of GitLab Ultimate. We hope you're excited to see what your team can do with it. I will also chat that link. And finally, if you have any other questions, please don't hesitate to reach us via our sales contact page about.gitlab.com slash sales. That's all for today. Thank you so much for joining us.