 Thank you all so much for coming out this afternoon, really, really appreciate you taking the time to be with us here today, learn a little bit more about GitLab, throw some axes, drink some beer. We really, you know, our company exists and because of you, I love this company, I love this product and I love what I do and so it's because you guys use the product and give us the feedback and love it. As Brad said, I'm a solution architect. My job is to help you adopt and love GitLab as a product and to make sure that you're getting the most out of it, getting a lot of value out of it. One of the kinds of value that we treasure the most that GitLab brings is that it helps speed up software development and deployment. If we're not helping you go faster, then call us up and find out what you would be doing differently because there are lots of things inside GitLab that can help you go faster and that's one of the things that we're here for. There are some other things, but that's one of them is really to help you go faster. That's absolutely critical to us. So I like to call this seven ways GitLab Premium will accelerate your development and we're going to talk about going faster and I'm going to talk fast because I got a lot of stuff, so let's go in. Number one, good one, thank you. Are there any particular questions about GitLab that you want to make sure we talk about in this session that are on your mind that you came with today? What are they? What are they? Yes, sir. I'm sorry. He's using Bitbucket. Yep. Yes, we can talk about that. And if I don't touch it during the talk, make sure to grab me afterwards and we'll go into it deeper. What else? Yes. What is the features of Kubernetes running? These two guys in the front here are going to have the really technical runner questions. So I'm going to touch on that. Let's talk about it afterwards too so we can follow up on that. We'll make sure you find the issue. What else? Yes. How do you make sure you're an expert in all of them? Am I supposed to be an expert in all of them? Because I'm still working on it. That's a great question actually. It's a fantastic question. How do you make sure that you kind of know what all is there even, right? Yeah, what else? There was something over here? No? Yes? Chad, you got a question? Static vulnerability scanning. You want to hear more about that? All right. Have you been using it? Excellent. Excellent, I love it. Yes. Is it possible to have different people in your company have different subscription levels, different tiers, we call them. That's a big one, yeah? 10,000 people. All on ultimate. That's the best. That's the awesome. Wait, I'll remind me to get to that at the end, OK, because I won't naturally hit it. What else? More visibility on your pipelines without having to dig into individual projects. And there is a new feature in 12.3, I think, that addresses that. There's a new group level pipeline view. If it's not in 12.3, it's coming in 12.4. I can't remember, but yeah, it's been. Do you have any integration? Integrations with other tools, yes, absolutely. There's a lot of that. So JIRA being the one that we integrate with the most, the security scanners you can integrate with through CI. So these are all great questions, I love it. I'm going to touch on probably a quarter of those during the talk, but we'll make sure we get to them afterwards. Thank you all so much. Seven ways GitLab Premium will accelerate your development. You're going to have to help me count them. So this is number one. Number one, GitLab is a platform for DevOps automation. I always like to start here because our name, the name of our company, has six letters, four of which we share with another company name. And people tend to kind of think instinctively that we are just like that other company. And in fact, GitLab does pretty much everything they do, times 10. And so the main thing that we bring to the table, the core, the heartbeat, if we're talking about acceleration, the engine that accelerates your development is the automation platform, which is CI CD, but I like to call it the platform for automation. So this is GitLab Flow, which is our kind of standard recommended workflow for using Git when you're using GitLab. It's kind of a variation on GitFlow, which came out a few years ago. And it's all about the feature branch, right? This is your feature branch. So we recommend when teams are working, you don't commit directly to master, you work on a feature branch. You guys are, it's a lot of pretty advanced Git users in here, I'm pretty sure you're probably already doing that. And we also recommend that you do as much as possible in the feature branch as early as possible. That's what we call shift left. And that's the number one way you can get faster speeds out of your development and deployment process is by doing more of your testing, more of your code review, more of your security scanning, more of your stakeholder review in that feature branch before it even gets merged, so that you can make sure as soon as possible after a developer makes a change that you're verifying that that change is correct and works as expected. Because the sooner you can find those problems, the quicker they can fix it and get that functionality delivered. So you have your CI pipeline, you have your review app, you have your peer review, your code review and discussion. You have approval, whatever kind of approval processes have to happen. You have your security scanning if you're doing it all before you merge. And GitLab helps you manage all of that as part of the automation. And of course, the kind of the core of the automation is the CI CD pipeline. You guys have all seen this? Raise your hand if you've never seen a GitLab CI pipeline and this is all brand new to you. Brand new, Brad, shut up. So as you know, GitLab pipelines have stages. The stages run sequentially. You can have one or more jobs running in a stage, except that's not the rule anymore because last month we released directed acyclic graphs for GitLab CI so you can actually have individual jobs that kick off as soon as a preceding job finishes without waiting for the rest of the stuff in the stage to happen that can actually optimize your CI runs dramatically if you have complicated dependencies in your CI jobs. Yes? That's one question. Directed acyclic graphs. That's why I always explain it. Yeah. It basically says you don't have to wait for the whole stage to finish. So for example, if you're building an Android app and an iOS app and you have a build and a test for each, right? So you have your build jobs here and your test jobs here. Your Android app doesn't have to wait for your iOS app to build before it starts testing, right? You can actually say, oh, this job depends on this job and proceed. So it was one of the biggest complaints three months ago about GitLab CI and it's no longer a complaint. GitLab CI, the automation is all driven from YAML. It's a declarative file format. It is super, super easy to get started with. Trust me, because I had to learn it and I learned it really fast. And the YAML file, one of the kind of the magic secret sauce is that the YAML file lives in the repository right alongside the code. So unlike a lot of configurations using Jenkins and other CI tools where all the CI configuration is kind of over here in this other world, this lives right there next to your code and can be branched and managed alongside your code. And that's absolutely important. If you're not so sure how to get started with GitLab CI, we have templates for the YAML. These are all public. You can read them, you can copy them, you can use them. You can even include them in your projects as they are if you want. And we've got a lot of the common programming languages in here, you're doing some elixir work. Great, why don't you pull on the elixir template, the Ruby template, the Python template, the C++ template, the .NET template. And up here are actually what we call the autodevops templates, which include the build and test and security scanning jobs that are included in our autodevops package. Those are all also public. You can read them, you can borrow from them. Go ahead, steal, these are open source. Great for getting started with YAML. Autodevops itself, who's heard of GitLab autodevops or used it? Okay, some of you have heard of it. It's actually amazing. I'm a big fan of GitLab's autodevops, but you kind of have to know what it is. Autodevops is an encapsulation of the best practices for GitLab CICD by the best CICD engineers that people actually at GitLab who work on it. It basically does everything you need with no work at all for certain kinds of applications. So if your application is a database-driven web application in a common framework, like Rails or Django or Play or LaraVal or something, then autodevops will probably just work out of the box. When I say work out of the box, you configure your Kubernetes cluster, you check a checkbox, that's it, and then boom, it detects what language you're running, it builds the Docker container for you, it puts the Docker container in the container registry, it runs your unit tests and your integration tests, it runs any static scans that are within your license tier, including all these security scans. It deploys to review app on your Kubernetes cluster with the hostname and SSL certificate all ready to go so it's completely isolated and with the database all completely isolated from all the other review apps. If you've got 10 engineers, we're gonna in 10 merge requests, you have 10 review apps and the stakeholders for those 10 changes can all review those changes in that branch, in their web browser. It runs scans on the review app, so things like your dynamic application scanning reports all that scan information back into the merge request so the developer can make changes right away. Then after you merge, it deploys to staging using a Helm chart, that's a Kubernetes thing, by the way, Helm charts, kind of the tool for doing deployments into Kubernetes, running any post deployment steps like database migrations and then there's a manual step to deploy to production so you actually have to click the button. Yeah, I like that change on staging, I'm gonna deploy that to production, click the button, you can deploy all of it to production or you can do a canary deploy, you can do rolling deploys and you can even instrument it for monitoring using Prometheus, all automatically done for you. What's more, if you don't wanna do all that, you just want part of it, you can actually steal part of it to use, you can take the whole auto DevOps thing and override parts of it, so it's actually a template that you can work with, it's a really great starting point for this kind of application and even if you're not gonna use it, you at least might wanna read those templates to get some ideas around how to do your own CI. So auto DevOps is one of the kind of key things that we provide to help you accelerate your development. That's number one is automation. Number two, am I at two? Yeah, am I counting right? Okay, I need some verification, thank you. Governance of code changes. So all that information from all those scans, all those tests, all those reviews, all ends up in the merge request. The merge request is tracking your change the entire time that it's being worked on right up through and even after it's been merged. Now, when that other company first came out with pull requests, it was kind of something that you did at the end. You would fork, you do your work, when you're happy with it you'd submit a pull request saying, hey, this is a change you might want. Merge requests in GitLab are a little bit different. We recommend creating the merge request when you create the branch at the beginning because that's where you track all that knowledge about what's happening in that branch, all those test results, all those security scan results, all those code reviews, comments that people have made, thumbs up, thumbs down, emojis, everything. All tracked in the merge request and so it's absolutely key to have a merge request for your branch. This is a merge request. You can see here, this is the branch you can click through, this is the pipeline. You can see the stages of the pipeline that have run. You can see the security scan results. You can click and open up deeper information about the security scans. There's discussion down here and code review and everything that you might need all in one place, all in the merge request. The merge request is kind of the centerpiece. It's kind of the, oh gosh, I already used the engine as an analogy. I don't know, it's like the body of your automation. GitLab also comes with a built in web IDE so you don't even have to download, you don't even have to pull and run your IDE on your local machine if you don't want to. Now, most serious developers, they got their VI, they got their Emacs, they got your VS code, you got your Visual Studio, you got whatever the heck you guys use for your old classic ASP. I don't even know if Visual Studio still supports that. And you got your Eclipse, right? Sure, of course, that's what you do. But if you just need to make a quick change, the web IDE is integrated with the merge requests. You can make the changes in the branch, you can make multiple changes and commit them, set the commit messages, make new branches, everything all from within web IDE. So super powerful way to make those quick changes really quickly. Code review is built in. You do not need a separate code review tool. Last night, we did an event like this in LA and our speaker was from Ticketmaster who used GitLab end-to-end for everything in their company. And she reminded me that in the olden days, code review was a meeting where people would sit in a room and put the code up on the screen and talk about the code, which I think is really funny because I totally had forgotten about that because code review now happens in GitLab. And not only can you see the changes and comment on the changes, you can also recommend that maybe you might want to write this a little bit differently. You can require that your recommendation be approved before it be accepted. There's a whole workflow around code review built into GitLab so you can make sure that the best minds in your organization are having the input into every change that gets made. Furthermore, once you've done all your tests, your scans, your review apps, your code reviews, your discussion and everything, you can set up approval workflows so that this merge request can only be merged if certain people approve it. Now, this is a very complicated example. I've got like, QA team here has like 10 people and two of them have to approve this and only one of them has, right? But that's kind of a group-oriented code review configuration. All of that is possible using GitLab Premium. There's also code owner reviews, which is where you can designate parts of your repository that are owned by certain people. And somebody in that group has to approve any change to that part of the repo but they don't have to approve other things. So you've got like the documentation section and you want one of your writers or editors to approve any change to the documentation folder. You can do that using code owners. Once everything is approved, you can merge and merging can happen within GitLab. It's one big green button and you can enter your merge commit message. Of course, you can pull down to your local machine, you can do the merge locally and push it back up and all the same permissions and everything apply, but there's a big green button here and it's super fun to press. What's more, if you have multiple merge requests outstanding at the same time, you can now configure what we call merge trains where your test runs run on what the merge commit will be if the merge were to happen today and you can actually sequence your merge requests and make sure that they pass in the right order and that they're kind of, what we call the pre-flight merge. So you can actually name in the merge process so there are no surprises when you click merge because sometimes you click merge, it's like oops, somebody made a change to master, I didn't know about it, the merge didn't go through, boom, you can prevent that now with GitLab. That's yet another way to help you run faster by using this strong governance of code changes throughout the entire pipeline. Okay, what was that? Crossfade. No, what number was that? That was two, this is three, oh my God, I gotta talk faster. Okay, integrated agile planning, who uses JIRA? Not so many, okay, who uses Pivotal Tracker? I had one last night, it was fun. Who uses Excel, yeah. Who uses GitLab issues? Woo, woo, okay, we use GitLab issues a lot, we use GitLab issues for everything. The reason we built an agile planning tool into GitLab is that you can start to take advantage of these end-to-end integrations to help you go even faster, okay? I guarantee you your teams will work faster if you use GitLab issues than if you use JIRA, even with our JIRA integration. We integrate very deeply with JIRA, a lot of our enterprise customers use it and are stuck with it, but I guarantee you you'll go faster if you're using GitLab issues because the issue is where it all starts and the magic here is that this is a GitLab issue, okay? Library tempura, something, something. The magic is this button right here. This button, right here, don't worry camera people, I'm coming back, allows you to, from an issue, it says create merge request, it does so much more than that. This is like the magic button. You're looking at an issue, you've been assigned this issue or you've assigned it to yourself and you're like, I'm gonna work on this issue, developer's gonna work on this issue, right? You click that button, it creates a branch, it names the branch after the issue, it creates a merge request, it names the merge request after the issue, it connects the merge request to the branch and it connects the merge request to the issue and it leaves you looking at the merge request ready to go and in fact, if you don't wanna work locally, if you wanna work in the web IDE, you just click one more button and it opens the web IDE and you can start editing code right away in your branch, in your merge request, all the power of GitLab in two buttons. That's how easy it is to work with GitLab if you're using GitLab issues. Issues themselves have everything you would expect, you can do descriptions in markdown, you can have related issues, you can have, these are the merge requests that are related to this issue, you can align them with milestones, epics, you can do time tracking, due dates, labels, everything that you might expect from a fully featured issue tracker is right here in GitLab. We have Kanban boards, you can drag and drop between the different states, you can actually organize these boards in different ways, for example, they don't have to be by label, they can be by milestone or by owner, however you want the columns to work. You can configure milestones and set schedules for the milestones, we use this for GitLab, this is actually GitLab's milestones from a little while ago, 12.0, 12.1, we're on 12, we just did 12.3, so now we're working on 12.4. And with the milestones, you can do burn down charts so you can see exactly how your work is tracking relative to the milestone and when you merge a merge request, it closes the issue that's associated with that merge request, so that's all end-to-end synchronized. Once again, allowing you to work that much more quickly with the integrated agile planning. Okay, what was that? That was three? Okay, number four, woo! It's better than Jenkins! I added this section in because we get asked about it so often and I truly and deeply and passionately believe that it's better than Jenkins. Are you agreeing with me or are you gonna argue with me? What are we gonna support the broken plugin model? Yeah, I can tell you, it's never. And in fact, we're adamantly against plugins. We say if you wanna add features and functionality to GitLab, add it to our open source project and contribute it back to the community. That's our answer to plugins. You don't have to read all this. There's a lot of words on the screen, I realize, but this is information, most of this from Jenkins and about Jenkins and just why GitLab is so much better. I love this. I mean, this was just last year that the guy who wrote Jenkins is talking about brittle configuration and assembly required and reduced development velocity and it can take hours to days to get it set up and configured and everything. In GitLab, you just drop that CI file in there or hit that auto DevOps checkbox and you've got your CI. There it is, ready, ready to go. Good to go, get started right now with it. So it's that easy with GitLab, it's built in. This was a hacker news thread from earlier this year about Jenkins and I didn't have to try hard to get these quotes, utterly disappointing, hard to configure, fragile. And then GitLab, the best CI I've ever used. If you don't like our fan club on Hacker News and it kind of is a GitLab fan club on Hacker News, I don't know if you read it, you can look to Forrester, which my colleague Ty talked about Forrester quite a bit, which two years ago in their survey of CI tools across the market rated GitLab a leader. And so this is leader in CI overall in their cloud CI tool survey that they just did which is the one Ty was talking about, put us right up there with Microsoft, Amazon and Google. So we're clearly recognized as a leader in CI and we're better than Jenkins, period. So that was, what was that, 16, 29, that was four, thank you. Okay, number five, Kubernetes integration. Who uses Kubernetes? Yes, oh, I love it. You guys know more than me, you should be up here talking instead of me. We, GitLab decided a couple of years ago to go all in on Kubernetes and kind of accepted this idea that cloud native application deployment using Kubernetes is the direction that the industry is going and that we were gonna support Kubernetes out of the box and we're gonna make it really, really easy so that companies are adopting GitLab as an on ramp to Kubernetes. It's really kind of like the, oh, we've gotta get into Kubernetes, how do we do that? Oh, GitLab, right? That's kind of where we're going. And this is really how a lot of this op stuff happens. I'm just gonna zip through some of this. This is a deploy board. So if you're using GitLab to deploy to Kubernetes, you get this wonderful, easier environments. This is 23%, you're doing a rolling deployment into production and the new version is gone to 23% of the servers, right? You can see that right there of the, sorry, not the servers, the pods, right? You can do canary deploys. You can do Kubernetes monitoring directly in GitLab so you can monitor all your Kubernetes cluster. You can actually launch a web terminal from within GitLab to log into your nodes and do your troubleshooting directly from within GitLab. The integration is super easy to set up. You just click some buttons. You give it the token and everything for your Kubernetes cluster and you click some buttons, get your Helm tiller installed, get your Prometheus installed if you're using it. And it's just super, super easy. I knew nothing about Kubernetes when I started to GitLab in January and now I'm just rocking it with Kubernetes because it's so easy to use with GitLab. And so that was number 67, what was it? That was five, okay, number six. GitLab has more architecture options than any other DevOps tool in existence. I'm pretty sure. I make a lot of bold claims, I guess I'm in sales, but first off, there's GitLab.com. GitLab.com is the exact same code base as the self-managed version of GitLab. There are a lot of companies that will sell two completely different products, Atlassian, under the same brand, Bitbucket, and kind of say it's the same and it's not the same. It's totally different. And they've got two different dev teams and they've got different problems and everything. It's the same code base with GitLab. You can get started now, it's free. It's even free to do a 30-day gold tier trial and you can try all the functionality you want to on GitLab.com right now. But if you wanna deploy it yourself, as many of our enterprise customers do and all of our government customers do, we give you tons of different options and ways to deploy it. From public clouds to your own infrastructure to VMware to Kubernetes, however you wanna deploy it, we'll support you and work with you to get that deployment happening. Or if you want our recommendation, we've got some recommended deployment architectures depending on your level of usage and which of the different features you're gonna be using. The core product is open source. And so there's a core free tier product which is completely open source under an open source license. And even the paid tier functionality is actually published source code. You can read the source code and you can see what it is. We don't hide anything. That includes, I was talking with, forgot your name? No, the guy behind you? Chris, earlier about issues. All of the issues that we're working on for GitLab and all of the issues that have been proposed for GitLab are all open. All the merge requests are open. They're all published and shared publicly. So you can go in, if there's certain kind of piece of functionality you wanna see, go in and create the issue. Go in and see if there's an issue already there. Add a comment to the issue. We really, really believe in our community of 2,000 some developers who've contributed to GitLab and we continue to share absolutely everything that's going on. It's a little bit of varying our dirty laundry to be honest. I mean, you also see all the mistakes and stupid ideas that people have. It's kind of a mess sometimes. But at the end of the day, we believe that it brings us more value and helps make GitLab more valuable so that you can work faster. And our product vision is even public so you can see where we're going with each section of the application and what's coming in the upcoming releases. And that's all published and shared. Finally, I would be remiss if I didn't talk about the speed advantages of our high availability and global distribution architecture options. If you've got a dev team in India, put a GitLab node in India and we'll synchronize them to keep them in sync so that those developers in India can do really fast pushes and pulls without any latency and yet still be part of the same development organization or wherever they are. We have some of the most advanced geographically distributed replication that there is in the Git world. Yes? What about China? What about China? Again, you can put it anywhere. I don't care where you put it. We don't manage those nodes. That would be you putting the nodes in your data center or in whatever cloud provider you're working with. So you can put them wherever you want. Yeah, this is just the architecture that we will help you with and we'll support it. Okay, that was six. Number seven, GitLab itself is a fast growing and reliable company. Five years ago, we were seven guys in a van in Y Combinator. Today, we are, that lies, 916 employees spread across 56 countries worldwide. We do not have an office. Everyone works at home and we've supported over 100,000 organizations literally millions of users are using GitLab around the world and as you know, we're pretty well financed right now. Companies you have heard of are using GitLab. I've gotta add Petco on here and Ticketmaster. I don't know, they gave me this slide. This is maybe a little out of date. So we're adding new logos all the time and that's not just corporations. It also includes government agencies. Government agencies love us because of our auditability. Having everything in one application makes auditability really easy and regulatory compliance. And also, we're huge in Europe also. There's tons of companies in Europe using us. As Ty mentioned, we cover the entire DevOps lifecycle and there's development going on in each of these areas. One of the things Ty didn't mention is that we're very unusual. Well, we're unusual in a lot of ways as a company. One of the ways is that we land all this new funding more than half of that funding is going into product development, hiring more engineers and product managers in order to build out all these phases. A lot of companies at our stage, they basically freeze their dev team and they just blow out the sales and marketing. They think, okay, we've got the product, now let's go sell it. We don't think we've got the product. We think we've got 10% of the product. And over the next few years, you're gonna see GitLab become a more and more comprehensive tool for doing everything you need across your development lifecycle and integrating those things completely and thoroughly. Our technical support team is global in every time zone available 24-7 to premium customers. Our customer success team, that's me, is there to help you, including technical account managers who can work with you to help you get implemented. And we have values that matter, including transparency, which I talked about, iteration, we do everything in little small increments so there's always improvement going on and collaboration results, efficiency and diversity. And that is how GitLab Premium will help you accelerate your development. Thank you. That's it? You want to touch on the questions or just do one one? We're gonna touch on a couple of the questions. Can I do that? Yeah, come on, let's do. Okay. A couple of people asked about security scanning. Security is one of the stages. If we go back, boop, boop, boop, boop, boop, boop, there, boop, boop, there. Okay, secure is here. So we have static application security testing in over a dozen different languages. We have secrets detection. We have license management. It's not called license management. License compliance, it's called now. Container scanning to scan all your Docker containers for known vulnerabilities, dependency scanning, also in like a dozen different languages. We have dynamic application security testing, browser performance testing, and Ty, what have I forgotten? We're working on IAST, which is interactive scanning. Most of that functionality requires the ultimate tier, which is the highest tier of our licensing, okay? And so that's one of the reasons I don't talk about it very much in this presentation, because I kind of stay focused on premium. But, and a lot of it is, you'll notice is in the, what we call the viable stage, which means it's usable, but we're still working on it. And there's a lot of improvements going into those. What were some of the other questions that you guys had asked at the beginning that I haven't touched on? He wanted to hear more about. We'll have to do a little search and GitLab issues and find out about that. I mean, getting GitLab running on Kubernetes and getting GitLab runners running on Kubernetes is an important thing that we're working on. And virtually every release there's new stuff coming out. I know the big focus for auto scaling runners is on Docker machine, but the idea should be that you should be able to run those on Kubernetes also. I mean, that's definitely the future. Yep. Okay, what were the other questions that I haven't touched on? Or do you guys want to wait until like food? There's food, by the way. So, yeah. Pricing tiers. Pricing tiers. Okay, we're not gonna talk too much about pricing tiers, but the basic rule of thumb is that the license is per user and the license is for the instance. The three tiers, starter, premium and ultimate. And when I say the instance, I mean the installation of GitLab. The three tiers, starter, premium and ultimate are really designed to appeal to different sort of different types of organizations at different stages on their DevOps journey. And because so much of the functionality is integrated and a lot of it is cross project functionality now, it's not really that easy to sort of say, yeah, this guy's only using the starter tier, but this guy gets access to the premium tier. Well, what if this guy commits code to a project that was on the premium tier? It gets complicated really fast. Having said that, if pricing is a problem and you really have business need to go to the higher tier, then talk to us about it. And we're definitely willing to kind of listen to your needs. We want you to be successful with GitLab. We want you to love GitLab. The pricing is kind of designed some more like the big enterprise companies go to the ultimate tier, but it's definitely something where we can be flexible about. But it is a very simple model. It is per instance, per user per instance. Okay, what else? Somebody's converting from Bitbucket. How many repos? 40 repos, how many users? 200. 200. 200. 250 users. 45 users or so. Okay. Typically if you're taking that many or 200, 250 users. And 200 repos. 200 repos over from Bitbucket to GitLab, our recommendation would be that you bring in our professional services team and we sit with you, go through your requirements and do it for you. That does cost some money, but there are guys in our pro-serve team who do that every single day and they know exactly what the pitfalls and the ins and outs are gonna be of that. Now if it's really just the Git content and you don't really care about your pull requests or anything, then of course you can just do a clone and a push, right? And you're good to go. But for 40 repos, that's gonna be a lot of work. And you probably wanna pull over your pull requests and your access controls and everything like that. So we recommend working with our professional services team. They have tools that they use, but we haven't open sourced or released those tools yet cause they're not quite, like they're kind of half baked tools that only the guys who wrote them know how to use right now. But we're doing it all the time. We do Bitbucket conversions literally every day. I mean, it's like it's that that often. Yes? I will say we have a concept. Ooh, he's doing bidirectional mirroring between Bitbucket and GitLab. Bitbucket cloud or server? Bitbucket cloud. Bitbucket cloud and GitLab. Okay, cool. Including pull requests to merge requests or just the Git repos. You do all the merge requests in GitLab. Bidirectional cloning between GitLab and Bitbucket. There's another speaker for a meetup. I'm recruiting you guys. Okay, let's take one more question and then we're gonna break for food and any casual chit chat. Who's in? Who's in? Who's got the last question? We're just gonna sit here until somebody asks me a question. No? Okay, we're good. What's your favorite feature of GitLab? Oh, man. I'll tell you what, the feature I'm kind of most excited about right now because I can't say favorite overall. Most excited about right now, believe it or not is feature flags, which is down here. And it's kind of been recently added very quietly in there. What it allows you to do is you can put the agent in your application and then within GitLab you can turn on and off different features and your application will immediately show or not show those features. And we're actually using that in GitLab. So when we introduce new features in GitLab we always have a feature flag and a lot of times the feature's actually live on gitlab.com but we haven't turned it on yet. That's how we test a lot of things. And what's really great about that is as we build that out you're gonna have the ability to say things like only certain kinds of users get this feature or only users in a certain or 10% randomly selected of users get this feature. And then when you start having your monitoring look at things like who's clicking on what and how much feature flags as a way, it's basically like a way of instead of doing canaries of whole deployments you're doing like canary tests of individual features. And it's gonna start unlocking an amazing amount of power. And I love that. I love those little features that are in there that are just gonna grow over time. Even how they use GitLab and our dev team because I don't want them just going out. And then it was fun to watch them because she's like, well, I don't want you to hide stuff. Like we want to see different stuff. Like why would you hide it from us? And then they have different perspectives but that's something that can be used. All right, thank you all. Thank you.