 Hi everybody, my name is Eric and I'm a product director here at GitLab. I'm so delighted to be here with you today in London. I've really enjoyed spending the past few days exploring London. In fact, yesterday I climbed all 839 stairs between the monument and St. Paul's Cathedral to get some great views of the city. My legs are a little wobbly up here today, so if I pass out, just come right up on stage and keep the keynote going. My note should get you most of the way there. Earlier today, you heard some great news about GitLab, and you learned about how some of our amazing customers are using the product. I'd like to give you a message through the lens of GitLab's product organization about some things we've recently launched, showing you a quick demo about how some of these new features integrate with the rest of the platform, and then close with some exciting announcements of some things to come. When GitLab first started out, it was just Git source code management with a little bit of issue tracking thrown in. But developers needed more than just that, and so we soon added GitLab CI to test and build your source code. That was a really good idea. Developers love source code management and CI together, but developers don't just stop when their code is built. You need to get your code into production, and once it's there, you need to monitor it to make sure that it runs the way you want it to run. And so GitLab evolved and continued adding ops features, and soon, we were covering the entire DevOps lifecycle. But in today's environment, when cycle time is key to improving your business, DevOps is not just about DevOps anymore. You also have to include security. Being able to run security tests on your first code commit shortens your cycle time by helping you find security vulnerabilities more quickly. And as needs of organizations grow to add ops and security features, oftentimes new tools are added to your tool chain. But the thing about most tool chains is that they're just not solving enough. In 2018, $5.2 billion was spent on DevOps software, and that's going to grow to $15 billion in 2023. And despite the spending, more than half of the time spent doing DevOps was spent on logistics and repeatable tasks, and almost 90% of organizations weren't fully happy with their DevOps transformation. And this is why. I mean, how many tools did you have to string together to form your DevOps tool chain? Everything from planning to building, testing, deploying, monitoring, and securing, that's a ton of stuff. And chaining these tools together comes at a real cost of integration. This is what we call the tool chain crisis. And the people needed to design and build these tool chains could be used to surface value to your business in other areas, but they have to maintain your integrations. But worst of all, the tool chain crisis reinforces what DevOps set out to destroy silos. When you have teams working in separate tools with different sets of data, that makes it so where teams cannot communicate together effectively. So what did GitLab do to affect and to change and address this tool chain crisis? We evolved GitLab to be a complete platform for the entire DevOps lifecycle. By utilizing GitLab, teams can now work out of the same application to manage their DevOps practices. And people who were previously managing those integrations can now focus on tasks that add real value to the business. We're providing an experience that not only treats developers as first-class citizens, but also operations and security professionals. These teams need to work together using the same data in the same tool, looking at dashboards that make sense to them to effectively execute their roles. So GitLab has to be the main interface for all of these roles. And we're building a unique experience for each of these professionals' needs. This is important because it's causing some huge wins for our customers. You've heard from Portia, who's triggered over 80,000 pipelines using the GitLab platform. Kiwi.com, who's accelerating their transition to cloud native and microservices architectures using GitLab. And Goldman Sachs, who we just heard from, who's improved from two builds a day to over 1,000 builds per day. Passler, a global network monitoring company, moved from Jenkins to GitLab and saw their number of releases increased by 400%. But that's not all. They also saw a 120 times increase in your QA team's velocity. The European Space Agency is another great example. As a result of working with GitLab, they've been able to deploy code in minutes when it used to take weeks, foster a culture of collaboration through the organization, and, but most importantly, take people who are previously managing their toolchain and put them on other activities. Another customer, Hemmersbach, a service provider focused on device as a service. By reorganizing their build chain, they've increased build speed by 59 times, moving to over 60 builds a day, and 30 automated daily deployments. These amazing customers now have a single application to manage their DevOps toolchain with a single source of truth, easily deploying changes, and quickly serving the ever-changing demands of their customers. In order to keep great customers and users like you happy and productive, we put a ton of effort into improving our product. Every month, on the 22nd, we release new functionality into the latest GitLab version. We've delivered some amazing things recently that I'd like to highlight to you today. DevOps teams are always trying to improve their CI pipeline, making them faster and more efficient. In GitLab version 12.2, we released directed acyclic graphs, or DAGs, for our CI pipeline. Yeah, we didn't buy for that. This allows users to create more complex and parallel pipelines. With the DAG, you don't have to wait for all jobs in a given stage to complete before moving on to jobs in the next stage, allowing for much more speedy pipeline execution. We've talked about the shift to have security operations professionals as first-class citizens inside of GitLab, but there are many other people involved in the software development process. The one of the most important personas here is the designer, and they need to work along the rest of their product team in the same tool. In GitLab 12.2, we released our first iteration of design management, allowing designers to version control, collaborate, and comment on designs used in their application right inside of GitLab. In our most recent release, GitLab 12.3, we launched the first iteration of productivity analytics, providing engineering teams insight into their team's efficiency. As more organizations undergo digital transformation, it can be hard to tell if it's actually working. Iterating on features like productivity analytics inside of GitLab will help our customers answer that question, is my digital transformation working? And in GitLab 12.2, we also released the ability to require an approval for merge requests, which introduced new vulnerabilities. This ensures changes are not merged unless specific people review and approve the change in the event that a vulnerability is introduced to your application. We've also released some great functionality for static and dynamic application security testing, monitoring, web application firewalls, and continuous delivery. In order to highlight some of this amazing functionality and show how it all ties together in a single application, I'd like to invite Dan Gordon to the stage to give us a quick live demo of the GitLab DevOps platform. Thank you. Thank you, Eric. Okay, as Eric said, thank you. Thank you. I'm Dan Gordon, and I'm... Geez, that is a lot of green. Okay, so here's what happened. We had some developers, they worked on some stuff, really cool, they rushed to get it out, went through all the tests, but we forgot to change the default page. Simple fix. We're going to go ahead and open up a quick issue. In GitLab. And we use the issues to capture the work that needs to be done. We can include screenshots, a little bit of description. We can have a discussion about it. But the great part is, after we've collaborated and agreed what we're going to be working on, is all we've got to do is press Create Merge Request, and I'm off and running. GitLab is going to get us all set up. It's going to create a connection to the issue that we came off of. It's going to create the branch that we're going to work in. And it's going to tie all those together so we instantly have traceability across all of those pieces. Now, at this point, I can jump into our Web IDE and I can start editing the code or doing what I need to do, or I can use my own Web IDE, my own IDE, or I can go VI on the command line, whatever you're comfortable with it is, Git that we're going to be using. So when I put everything back, it's going to end up back in this merge request. Now, I'm going to do a cooking show thing here so you don't have to see me go through all the editing and we're going to just switch over here to this merge request, which is the same thing, except we've already run through it. So we'll have all the data here ready. So at this point, I've done some commit, or a commit, and that actually, as I just mentioned, comes into the merge request and those changes are visible right again from that central location, from the merge request. So I can see here that I changed the background color. I changed the message and I added a logo. Simple change. And what GitLab did was, right after I did that commit, is it fired off the pipeline. So let's take a look at that pipeline. Now, this pipeline is what we call AutoDevOps, which is really just a best-practice pipeline out of the box that's ready for you to use. You can create your own pipelines to do whatever you want them to do. You can actually pull in components from this pipeline that you're looking at into your own, or you can just go with the default pipeline we've set up. This is best practices that we've accumulated over working with thousands of different companies for their DevOps initiatives. And what this will do is not just give you a template out of the box, but it will also give you the actual scanning tools and the actual tools that we're running. So you don't get a template and then have to get the tools and install them and then configure them and integrate them into your pipeline. It just will work. So right out of the box, I put my code in. I'm going to get a build, which is going to happen automatically. It's going to take the result, put it into a Docker container, upload it to the GitLab Docker registry. So now it's available for us to use. Right after that, six tests are going to kick off in parallel. You can see those here. The system will scale as necessary. And we're going to do automatically code quality checks. We're going to do container scanning to make sure your application environment is secure. We're going to do dependency scanning. To look out at what your code is dependent on and make sure that we understand the vulnerabilities that come with those and that we can identify those and resolve those. Just the same, we're going to be looking at those dependencies and we're going to be checking the licenses this time. So license compliance scanning is going to allow us to get a good sense of whether or not we're accidentally or maybe intentionally adopting licenses that are incompatible with our organization's policy. So some of those licenses may not be compatible with our business plan. And then we're going to run static application security testing where we're going to look through the code for vulnerability signatures that are known, things like buffer overflows. And we're going to highlight those to make sure that those get resolved or identified as well. And then we'll also at the bottom here run whatever tests that the developer has put in. After that, the system is going to fire up what we call a review app. Now this is some pretty cool Kubernetes deep integration magic where we're going to take the code that the developer has committed, hasn't been checked in to the main branch yet. It's just the commit to their branch. And we're going to spin up an entire environment that is basically a UIT or a staging environment that is unique and special for that change. Now what that enables is several things. One is the developer can actually interact with their application on every change that they make if desired. They can have stakeholders look at it, the business, the UX team, requesters, customers, and get feedback right away. And then that also gives us the ability to run tests like DAST, Dynamic Application Security Testing. So we can look for problems that you can't find just by looking at the code. So maybe, for example, configuration errors that may introduce vulnerabilities. And then because, again, we have a live application, we're also able to do performance testing. So we're going to run browser performance and we're going to make sure that the user experience doesn't degrade because of this change. So that's a lot of information. And all of that's going to run and all that data is going to come back, again, into this merge request. So here we see our merge request again and we've got the pipeline that we just went over. We've got a pointer to that review app so we can go see the changes that we made. That looks much better, I think. And we've also got all of the testing results, code quality. We've got security results and it looks like we actually got two new vulnerabilities. So right here from the MR, I can look at that vulnerability, I can get deeper into it, I can understand what it is, how severe it is, and I can start taking steps to resolve it. Not all the way at the end when we're about to go to release, right here, right after I made that change. I can create an issue, which is going to allow me to identify that I want to fix this. It's going to pull all that information over into the issue automatically and then we can make sure we resolve the problem or I can dismiss it. Now if I dismiss it, that's still going to show up in our security dashboard. At the team level, as our team is reviewing our project, we want to make sure that we're aware of all of the vulnerabilities that we haven't yet resolved. So for example, this one here, where it gives me extra information where I can go, for example, and go straight into the file and find out, okay, well, what code flagged that problem? So we can, again, be empowered as developers to fix the problems that we have, vulnerabilities, before we push it into production. Now we've looked at our security results. Let's say we're good there. We've also got our license scan results. No new licenses in this case, but I can't look at the full results. And against my policy, it's identifying a few licenses which our company is not okay with, so I can get a quick read on whether or not I need to go take a look at some of these components and maybe pick a different way to solve the problem. So let's say I've looked at all of that, I've checked my review app, I've looked at all of my results, and I'm pretty good with this, and I'll go ahead and merge it. So again, this is a baked pipeline. We already went ahead and merged it, but what it's going to do, GitLab is going to start what we call the delivery pipeline or the release pipeline. Now that pipeline looks pretty similar because we're going to run those tests again. We don't know what time has passed or what's changed since the last time before we deploy again. At this time, it's going to push it into staging and it's going to allow us to do a valid, final validation before we manually roll it out into production. This is an option. We can have it set to simply just go into production if we're ready for that. So that rollout's happened and that's going to affect the environment. So let's take a look at the environment. You'll see that there's a lot of items that we're not covering on the operations menu, things like serverless and Kubernetes config and feature flags. But for this demo, we'll just take a look at the resulting environments from all of the work we've done on this particular project. So I can first see I've got several environments production staging in that review app. I can go look straight into production and see it did get pushed. So there we're running our new code in production. I can see the information about the Kubernetes cluster. These are the five pods that I'm deployed into. And I can also go get pod logs if I need to do that and do troubleshooting as well. So I've got good information here. I can see what's going on with my environments. I can also get the details about what is installed in the environment historically. So at any point I can roll back and I can see the history of that environment. DevOps is not just about developers creating code and operations putting it out into the environment, into onto servers. DevOps is more than that. It's about that feedback loop, right? It's about getting the application out there and then understanding how it performs, how it adds value, whether or not it's having problems and understanding the changes we made and getting that tight feedback loop so that next development cycle we can continue to improve the software. So because of that, GitLab has monitoring built in automatically configured for every application that we deploy. We have monitoring information each environment, each application, such as error rate, latency, throughput, a couple other things here, as well as the details of the application as it sits on our Kubernetes cluster. So I can see my pod average from memory and CPU usage as well as the cluster. Now you'll notice something here. There's kind of a big spike that happened and you see that I wanted to figure out what's going on there. Now you see there's a few rockets down here and those indicate our correlation that we make between our deployments and the behavior that we see in our monitoring. So right out of the box without any work in configuration, I've got that information available. Let's actually go ahead and zoom in to just this one so we can see what's going on there. And I should be able to get over to the change that actually was deployed and I just lost it. So here I see the deployment that happened that caused that that might have been the reason for that spike and I have all the information so it's been linked to the issue so I know why we made that change. It's linked to the MR, the merge request so I can see the history of the testing and the discussion and the decisions that were made and we can also go down and look at the code changes that were made. So that's pretty good for troubleshooting and I think that's actually pretty amazing to have that all in one application right out of the box and that is a complete DevOps platform as a single application and that is GitLab. Thank you. Thank you Dan, that was fantastic. So where do we go from here? The slide behind me you've seen a few times but just to double click into it this shows the 10 stages of the DevOps lifecycle as we've defined them and then each bullet underneath here is one of our categories, a collection of features and functionality. The balls indicate how mature these categories are as you can see some of them are hearts and some of them are empty. The hearts are what we call lovable meaning that they're best in class or some of the best products on the market. The empty balls are functionality that doesn't yet exist and that we're planning on doing. It seems like an ambitious target to launch and maintain and improve all these categories at the same time and what's funny about this is I also thought that before I joined the company I remember going to the GitLab homepage seeing this table and if you go there today you'll see an additional row on the bottom of the table which outlines tools that GitLab can replace. Having been in DevOps a long time I remember thinking it was a little bit crazy that a single company could replace all of the heavyweight incumbent tools out there but after being here for a while I think it's possible and not only that I think it's the best way to manage your DevOps tool chain and looking back we've got a pretty great track record of delivering improvements you can see that our pace of innovation is rapidly improving and while GitLab the company is growing GitLab the community is also growing we have over 2,500 contributors in the wider community and those individuals are merging over 200 improvements back to the product every single month GitLab is open core and people from the wider community are contributing which is super exciting to see some organizations are even paying people to contribute back to GitLab full-time all of us are co-creating GitLab and together we're working to make DevOps a reality for everyone and as Sid mentioned this morning we just raised $268 million in series E funding and over the past few weeks I had the awesome opportunity to be a part of our CEO shadow program a program that's available to GitLab team members to shadow Sid around for a two-week period nearly everywhere that he goes it's an incredible opportunity and it's unlike anything else in the industry and as part of that program I got to Sid in on a lot of Sid's media interviews there were a lot of different questions but almost every single reporter asked what are you going to use all that money for and I'm here to tell you that a large portion of those funds will be used to increase our research and development teams increasing our product engineering and user experience we want to make every category lovable in fact we're going to make half of these categories lovable by November 18th 2023 to accomplish our goals we've had a 300% increase in product management alone in 2019 and engineering while having incredibly ambitious hiring plans has also kept up to date GitLab has grown from 19 members in 2015 to more than 900 team members in 59 countries today in January of 2017 we had 27 people on our development team and now we have over 200 during that same time period product moved or grew from 3 people to 32 we've 10x'd everywhere part of the reason we've been so successful shipping, delivering, raising money serving our customers needs is because we've lashed on to this idea that experiences are better when delivered as a single application and we think this model should be rinsed and repeated in other areas that are primed for disruption we've identified the first area where we're trying to repeat this and I'm excited to tell you about another project inside of GitLab Meltano Meltano is an open source data to dashboard workflow platform and it's launching its v1.0 today Meltano is a six person internal startup with inside of GitLab that's applying the best practices of software development to the data management workflow if you're interested in learning more about Meltano the GM of Meltano Danielle and Yanis, one of the team's developers are here today in the front row and they'd love to speak with you after the keynote additionally Yanis will be providing a demo of Meltano later in the day and the details are on this slide and as a fun challenge see if you can find out what Meltano stands for and here's a hint it's an acronym but that's the GitLab this is our GitLab maturity improvement plan and it's right there in our handbook transparency is one of our core values at GitLab and we built a page that shows the world how we're progressing against those maturity plans that we've outlined to you and how we're going to progress over the next nine months in order to make this graph a reality we have some great functionality that we're planning on releasing and I'd love to highlight some of that to you today in the manage stage we're going to invest into value stream management which is the ability to measure your DevOps transformation it provides efficiency metrics and over time we'll provide insight and recommendations right inside of GitLab to help you drive even more efficiency and value creation in your organization in the plan stage we'll be releasing requirements management which is the process of mapping high and low level requirements to individual lines of codes of code and tests if you're in a regulated industry you're likely using a third party tool to do this and we want to provide that experience right inside of GitLab the create stage is one of the best products on the market today with GitLab source code management and code review but we're going to continue to improve our web IDE to make it become complete and fully featured providing both client and server side evaluation and the ability to do live coding the verify stage also one of the best products on the market with GitLab CI in the future we'll be adding load testing as something that runs by default as part of your pipelines in package we'll be adding a dependency firewall that will prevent you from downloading dependencies that might contain a vulnerability or bad code in the secure stage we will be adding fuzzing as a default part of security testing fuzzing is automatically testing the boundaries of your code together with sasst, dast, and iast we'll provide a complete security scan delivered right inside of GitLab in the release stage we've made great improvements to incremental rollouts but soon we'll have great improvements for automatic rollbacks we don't want our users to have to babysit their deployments in the configure stage we'll be investing into runbooks to reduce mean time to recovery by codifying organizations' best practices for use in incidents in order to accomplish this we'll be making improvements into logging, tracing, and nearly every other facet of our monitoring product and in Defend I'm excited to announce that we just released our first feature in Defend our web application firewall in GitLab 12.3 and I'm personally excited that we'll continue investing here by launching real-time threat detection capabilities that will soon be coming to GitLab I'd like to double-click into two more examples of real-time threat detection capabilities two more examples of really neat things that we'll be launching in the near future the first example is the GitLab Runner just a quick show of hands who here is using the GitLab Runner? great, about half the room if you're not familiar the GitLab Runner is the functionality of GitLab that executes your CI jobs and sends back the result for self-managed instances it's hard to manage runner fleets so we're going to be providing the ability to autoscale both Windows and macOS runners and if you're a GitLab.com user you don't have the ability to use Mac or Windows Runner minutes on GitLab.com today so we'll be investing and providing a shared service for both Windows and macOS runners we'll also be investing in arm support and vault integration for secrets management and our second example today is auto remediation and I love this example because it highlights the benefits of dev, sec and ops all working out of the same tool auto remediation is the function of automatically fixing vulnerabilities that pop up most software projects today have upstream dependencies sometimes vulnerabilities pop up in those dependencies and usually there's a patch to fix them but you have to be looking for the patch and you have to test the patch and then you have to get that into production often requiring a lot of coordination for most organizations this task is manual and requires alerting but we think we can provide a better experience in this example a bot detects that a dependency has a new version likely because of a patch because of a vulnerability instead of alerting someone what if we just automatically created a merge request for you that bumps your version and then runs the test suite to make sure that everything still works there's some tools out there that will do this for you but most stop there because we are a single application we know that if your CI pipeline passes we can likely automatically merge those changes so if all goes well your security and dev teams just get an email saying that everything's been done for them and that all the projects have been automatically fixed but what if everything doesn't go as planned sometimes CI tests can fail outright and in that case we can alert the teams to go and look into it but sometimes CI tests can't catch things that only manifest in production but using GitLab monitoring we can automatically detect that there may be an issue in this example we see the error rates increase to five percent GitLab automatically detects this and then rolls back the deployment leaving master in a good state then and only then do we alert the teams that there's a problem to look into so that ties together dev second ops into a single platform letting everyone collaborate and work together better but do we stop at dev second ops? a ton of people are involved in the creation of software this is the ultimate GitLab vision where everyone involved with software development uses a single application so they're on the same page at all times so while we're still calling it dev ops we're really expanding the definition to one where everyone can contribute thank you so much for your time and attention it was such a pleasure to be here in front of you today I'll be at the GitLab booths during lunch if you'd like to talk say hi, ask me a question see you there