 For our first session of the day, I'd like to welcome to the main stage Anup Dwar and Christy Leneville. Anup is GitLab's VP of Product Management and Christy is VP of User Experience. Together, Anup and Christy will share with us some of the big wins and product milestones over the last year. Then we'll get a glimpse into the GitLab Product Roadmap as they share how we can innovate together on the next generation of DevOps. Good day, everyone. My name is Anup Dwar. I'm the vice president of Product Management here at GitLab. And I'm the vice president of User Experience, Christy Leneville. And before we start, Anup has an obligatory slide to share. Yes, I do. We plan ambitiously and our roadmaps are subject to change without notice. Please use this for informational purposes only. Okay, that out of the way. We are delighted to share a bit about what we've been up to and humbled that you took the time to attend today. I'll start off by sharing the overarching product themes for this year and then walk through some key problems we're looking to solve for you. Then I'll share some recent additions to our product and give you an update about how we're progressing on product maturity. And then I'll conclude with some thoughts about the future. I wanna start with the theme of this year's committee, innovating together. This is not something new for GitLab, but it bears repeating, celebrating and improving. Just in the first six months of this year, you contributed 1,709 improvements, 261 more than same time last year. This is astounding. Each month, we announce an MVP that has contributed in an outstanding way to help make GitLab better for everyone. I'd like to call out a few. Matthew contributed significantly to the package stage with his work on both the Debian and Helm package registries. Lee added time tracking report feature. This allows you to easily see who has spent time on an issue and even allows you to take notes. Yogi made multiple performance improvements to the GitLab status page and polished the UI. Admin mode would not have been possible without the heroic efforts of Diego. With this feature, GitLab administrators can use their account as normal users preventing accidental changes and then switch back to admin mode when needed. In 39, Andreas added GPU support in GitLab Runner. This change enables you to train machine learning models, render animations, or offload other calculations. And contributions don't have to be just code contributions. For instance, Rachel had the technical writing team and force consistent writing styles. In 13.7, Rachel opened 33 merge requests, helping the team chip away at this important task. Thank you, Rachel and Andreas, Diego, Yogi, Lee, and Matthew. And thank you to the entire GitLab community for believing in the vision and innovating together. This is a special community and you're fortunate to be part of this amazing movement. Continuing to talk about innovating together, over the last decade, product development has changed. A lot of different and specialized roles are now involved in making great software. And our vision is one where everyone involved can share context in the same environment and instigate collaboration, innovation, and efficiency. So while we're still calling it DevOps, we're really expanding its definition to one where everyone can contribute. It's our big, hairy, audacious goal to make GitLab the most popular collaboration tool for software development anywhere. And in order to help a diverse set of personas and users of GitLab focus on collaborating with each other, we want to reduce the time you spend on activities that do not contribute directly to your goals. Therefore, this year, we're focusing on improving our SaaS offerings so that you don't have to take care of upgrades and updates and can enjoy a managed, secure, reliable, highly available GitLab. We also found that in order to bring everyone from designers, marketeers, program managers, machine learning engineers, to developers on the same platform, the experience has to be frictionless and intuitive for everyone. So we are spending a lot of effort on driving usability improvements. And finally, we believe that finding, triaging, and fixing security issues as early in the product lifecycle as possible is really the only way to avoid existential security crises. Therefore, we are focused on providing you world-class application security testing capabilities. But those are just themes that are meant to make it easier for our users to absorb the innovations in the product. Now, let's talk about the big problems we are currently solving for you. I'll go over a few and you can find many more on our Direction page. Let's start with one that's probably top of mind for most of us. How do we help other teams adopt DevOps and do it well? Well, GitLab has a DevOps adoption report that you can use to compare your DevOps status to other organizations. It helps you verify whether you're getting the return on investment on your DevOps investment. It helps you identify specific groups that are lagging in their adoption so you can help them with the journey. It helps you find groups that are leading in their adoption journey so you can take the lessons learned from them and help everyone. We're focused on improving it further. Of note, we are adding security features in the adoption table to show which teams have and have not implemented security scan. We've also added a progress bar so that you can see how many capabilities a particular group has adopted. Another challenge we see is code complexity, volume and cloning are increasing. It's becoming harder and harder to learn code bases, to find and trim unused code, to understand the downstream impact of a microservice change, to audit your development policies. Not only that, lack of complete code-based knowledge is leading to duplications in consistencies, over-engineering, or more complex solutions. Therefore, we want to add the ability to filter code by attributes and meta details, meaningful to users, without relying on having the code, all the code in the local IDE. This will be compelling for all users of GitLab the need to find and work with code. You'll be able to do so with ease without having multiple prerequisites and setups. This will also allow more users to understand more code than ever before and make everyone more efficient and collaborative. Next, our market-leading SaaS offering. It's based on various and heterogeneous tools. While this approach was a great way to provide value to you quickly in our classic iterating fashion, it can also be limiting for the future. And what we've found is most of these limitations are coming from a lack of common code representation. Therefore, we are working on a next-gen engine that'll help you formalize general attack and vulnerability patterns and reuse them across languages. Learn new attack patterns and code smells across different languages. Release features such as code navigation and snippet matching. Mine for patterns across GitLab projects developed in, again, different languages and provide data flow and control flow to spot vulnerabilities that are impossible to detect without the complete understanding of the code. I can't wait for the team to up the game on SaaS again. Great job, team. And compliance can be complex and time-consuming. It is not about checkers checking checkers anymore. GitLab is creating a compliance experience that's built-in, not bolt-on. To make compliance easy and to have developers and compliance team truly collaborate, Christie will cover compelling offerings that are currently available in our compliance setup. I wanna talk about what we plan to do. We plan to give you more opportunities to define and enforce policies at an enterprise or a group level, saving compliance teams time. We wanna provide you visibility into what is happening, new audit events, web hook-based events, and then interface with external systems that you may already be using. I'd also like to share some exciting developments from the package team. The goal of the package team is to build a product that is our customer's single source of truth for storing and distributing images and packages. In 14.1, we saw a community contribution to add support to HelmChart that I alluded to earlier, and another contribution is underway for Debian. Both of these features will be dog-fooded, which will also drive internal contributions. We are very excited to accelerate the maturity of GitLab package registry, so customers can continue to rely on GitLab as a single source of truth. Exciting times. Meanwhile, our CICD teams have been busy enhancing our world-class CICD capabilities. You can now securely enable customers to authorize a bot to do the work on their behalf without compromising any other customers who use the bot. We made the CI job depend on a stage that's not directly preceding stage, so that can make it pipelines complete faster. We've enabled Pipeline Editor to work on non-main branches so developers can use them on their branches. And later this year, the team plans to help users see usage data of consumed CI so you can anticipate usage for your next month. GA of Mac OS Runners, something I'm really excited about, enhancing CI template experiences, and providing a project quality dashboard so app.dev.lead can see how the quality is trending in their projects and prevent escape defects and spend time shipping features and not bug fixes. And there's a lot more. All that built, packaged, and verified code has to run in production. And although customers are able to do container scanning as part of Pipeline jobs today, there's no guarantee that the image for the containers that are running in production has been scanned recently. Some customers have production container images that were deployed years ago and have not been updated. Users need a regular way to regularly re-scan their container images that are actually running in production so they can understand their security risk. So we are introducing this new capability which will allow users to schedule regular container scans of the images that were used to initialize the containers that are running in production environment. The container scan will identify known vulnerabilities in the operating system and in the packages that are installed on those images. And the scan findings will be displayed in a vulnerability report so that they're easy to consume and act upon. We plan to do this without requiring any additional credit credentials beyond what is already collected when connecting to your Kubernetes cluster to GitLab. And all these capabilities are great, but the administrators have to manage these at scale. GitLab features currently exist at three levels, instance, groups, and projects. While this is convenient, over time it leads to a few challenges. Capabilities like operations and security dashboard are hard to find. Capabilities unavailable at group level create a lot of toil for admins and they have to configure them on thousands of projects for enterprise consistency. Therefore, we plan to provide powerful, enterprise-wide management capabilities to scale to tens of thousands of groups and projects. We'll extract features from the admin panel that you are well aware of into a new object called Workspace. Workspace will include settings that apply to all groups, all subgroups, and projects in that namespace or instance. And then it aggregates data across all groups, subgroups, and projects. We're also working to simplify projects and groups so that there is feature parity in capabilities between group and project. And we want to implement cascading rules so that all the settings from a top level group or subgroup can be inherited automatically by downstream subgroups and projects. That's a quick trailer of our roadmap. And I'm equally excited to have Christie share what the GitLab team and community has delivered recently. Thanks, Anoop. Since the last commit, our research and development team has been working hard to bring lots of valuable new features to you. Because of our staggering velocity, there's no way I can cover everything and you'd be unhappy if I tried. Instead, I'm going to highlight a small subset that I think is really interesting from a user experience perspective. First, my personal favorite because I've got the stage and the UX team has been focused on this for a while, navigation improvements. Every quarter, we run a system usability scale survey where we ask for feedback on our product's user experience. Consistently, quarter over quarter, we heard that our navigation needed improvements and I'm so pleased to say that we released a first iteration of changes in the 13.12 milestone. Starting with the top menu, previously you had to search through three separate menus to find what you needed. So we consolidated them into just one menu that with a single click allows you to access groups, projects, milestones, snippets, the admin area, and more. In the left sidebar, we updated the menu items to better reflect how users think about and look for product features. And we minimized the negative space around each item so that the full menu displays without requiring you to scroll. We also completely refactored the code responsible for this area, which will allow us to iterate faster on this area of the product in the future. Many hours of research and design went into these changes and we've been enjoying the improvements ourselves now that they're in production. Moving on, we've added a lot of new features to continue our goal of helping you feel confident that your applications, services, and cloud native environments are secure. First, we know that security vulnerabilities don't stop once your application is deployed. In fact, new attacks spring up all of the time and you need to make sure that your application remains secure, even when you haven't committed changes that would catch new vulnerabilities in a merge request. With on-demand dynamic application security testing, you can scan your already deployed applications or APIs at any time, even on a regularly recurring schedule. You can also now specify authentication information, exclude certain URLs that you don't want to scan, switch between scanning web applications and APIs, save a scan to rerun it later, and select a specific branch to scan. We also released a security alert dashboard so you can more easily review and triage high priority security alerts from your production environments. This is especially useful when you need to closely monitor your network security without the negative business impact of blocking traffic. From a single location, you can view a list of Cilium alerts across all environments and clusters in your project, see when the alert occurred and the policy and environment that triggered it, and triage alerts into multiple statuses like unreviewed or dismissed so that you quickly know which items need your attention. Currently, we only integrate with Cilium, but in the future, our plan is to enable you to send security alerts from any security product. A common theme we hear in user research is the importance of having speedy, reliable pipelines that enable your team to contribute at the speed of development. We've made significant improvements to the way in which pipeline jobs are picked up and executed, and we've provided extensive documentation for optimizing your CI CD pipelines. We're also investing in your ability to rapidly get started and iterate on your pipeline definitions. Recently, we made improvements to the pipeline editor to help new users begin creating pipelines in a blank pipeline file directly from the editor page without the effort of creating a configuration file first. You'll notice that in the editor's right sidebar, there's a walkthrough tutorial on how to get started, and after you begin editing your pipeline, you can also visualize the jobs to make sure the hierarchy and relationships are set up how you intended. I'm excited to see these improvements to our user experience in such an important product area. Speaking of pipeline improvements, we've been working to help security, compliance, and development teams work together more effectively by introducing what we call compliance pipelines. Compliance pipelines help you meet specific requirements like SOC2 and HIPAA by enabling you to define a pipeline and enforce it for individual projects. The pipeline runs the jobs needed by compliance teams, and then it runs the jobs your development team defines. That means you no longer have to manually copy a pipeline configuration to every project and then monitor it to prevent edits or removal. Furthermore, your users can extend but not modify the pipeline configuration in downstream projects, so you can feel confident that compliance steps run the same way every time. This is a time saver for your security and compliance teams, but it also gives your developers more autonomy in following your organization's policies without becoming compliance experts themselves. Compliance teams also don't need to become development experts to understand how apps are being built and tested. This is one more step towards making compliance and development a collaborative relationship instead of a burdensome one. We know that being on call to manage incidents can be stressful, but we're trying to make those shifts easier through more intuitive schedule management. With our new on-call schedule management feature, you can establish schedules and escalation policies that include rotations and scheduled overrides, and you can route alerts within GitLab to the right on-call engineer for that specific project. Additionally, you can now integrate any IT alerting tool with GitLab by setting up an HTTP endpoint for that service with a unique auth token. For every HTTP endpoint you create, the resulting alerts get transformed into a consistent format that engineers can access from one location in the GitLab UI. That means they get consistent information all in one place regardless of an alert source. As we expanded our instant management capabilities over the past year, we realized that we were missing a subtle feature that has a big impact on user experience, the ability to change an issues type after it's created. For example, you might accidentally create a regular issue when you meant to create an incident, or you might decide that what was originally a regular issue now should be promoted into a more urgent incident. Now you can make that change by simply clicking the issues edit button and selecting your preferred issue type from a dropdown. Don't worry, you won't lose any important data like the description or any existing comments. You've probably heard us talk a lot about how everyone can contribute and that's not just lip service. We want GitLab to be the premier platform where knowledge workers of all kinds collaborate. And that means we have a wide variety of personas who use our product every day, not just developers and infrastructure engineers, but product and project managers, designers, marketing teams, and more. One of the key places that non-engineering roles contribute is in wikis. Previously, that could be challenging because the only option was to contribute using Markdown, a lightweight markup language that not everyone knows. Starting with our 14.0 milestone, users can now view content as rich text when they edit a wiki to lower the contribution barrier and make collaboration even more efficient. Soon, we'll add this same capability to other content areas like issue descriptions and comments. We'll continue to offer the ability to contribute using Markdown just like you do today. You'll just have more options. Now, even if you know Markdown, this is a great improvement because at least in my opinion, creating a Markdown table is notoriously tedious. So I'm personally looking forward to having this capability in more of our product areas. Speaking of contributions, merge requests are a key step in that process. We're working hard to continue making our merge request experience in our UI exceptional with ongoing performance and usability improvements. But we also know that not every developer wants to create every merge request in the UI. Sometimes it's easier to stay within your local development environment instead. That's why we released the GitLab MR extension that enables you to create a merge request directly from Visual Studio Code by simply providing a branch name and a commit message. In return, you get a link directly to your newly created merge request so you can quickly access it in the UI as needed. So as you can tell, our team is very focused on bringing user experience improvements to our product in every release. Now, I wanna talk about the work we're doing to increase the maturity of our product categories. At GitLab, categories are product areas that solve jobs to be done. We measure category maturity starting with planned, the lowest maturity, and then categories progress over time through minimal, viable, complete, and finally, lovable. Any maturity level above minimal is determined through user research that observes and interviews users and measures results objectively. First, I'm excited to say that our static application security testing category has moved from viable to complete. SAST is like having an automated security specialist double-checking for common security issues in your code. When enabled, it checks the source code of your merge request for known vulnerabilities and displays the results directly in your MR and on the vulnerability report. You can also access advanced configuration options in the UI. Our focus for complete maturity has been on making it easy to enable and effortlessly run out of the box. Our automatic language detection includes 23 different languages and even works for mixed language projects. For complex applications, you can run SAST across repositories that include multiple projects and customize your rule sets to disable predefined rules or modify the default behavior of an analyzer. And 95% of SAST jobs complete in five minutes or less, which means you gain security without losing efficiency. Also in security, we've completed the integration of Peach Tech API security product into our single platform, bringing our fuzz testing to viable maturity. Fuzz testing capabilities help you proactively find vulnerabilities and business logic flaws in your applications and services. You can now specify which assets you want to scan and under what circumstances by enabling fuzz testing from the GitLab UI. Then you can view any vulnerabilities directly in the pipeline of a recently run merge request or from a vulnerability report that enables you to triage them more quickly and easily. And last for security, vulnerability management is now also viable. With our vulnerability report, your application security team can see active risks, dive in to understand them better and quickly verify whether they've been fixed. They can also use bulk actions to efficiently move multiple vulnerabilities through workflow states. And for teams using Jira, your existing integration now allows you to create Jira issues directly from vulnerability records. As we move to complete, we'll continue to build on the current foundation while also refining the security experience for developers. Security teams can look forward to enhanced reporting capabilities, new automation options, and a host of other features to make managing vulnerabilities even more efficient. A redesign of the MR security experience will make it easier for developers to quickly understand and resolve any security issues as part of their regular workflow. And integrated training options will put highly relevant information right into the vulnerability details. Moving on from security, we have another category that is now complete. With snippets, you can store small blocks of code and text to make it easier to share and reuse. Now you can version control your snippets just like any other GitLab code repository, and you can star, fork, and clone your snippets too. And for a big upgrade, we added the ability to include multiple file types in your snippet. For example, you might want to reuse a mix of JavaScript, CSS, and HTML across multiple initiatives and multi-file snippets make that easy to do. Additionally, in our drive to make CI CD as collaborative and simple as possible, our pipeline authoring category has now moved to viable. As I mentioned earlier when talking about speedier pipelines, with our improved CI authoring experience, you can author, visualize, and lint your pipelines before ever making a single commit. Finally, I want to talk about a couple of categories that are near and dear to my heart. First, our design management category is now viable, and my own product design team uses these features every day to enable easier cross-functional collaboration. We personally use Figma and have been enjoying the GitLab plugin that makes it easy to upload design assets seamlessly into GitLab issues, but we support this capability for Sketch, another industry-leading design tool too. Even more exciting, you can now place comments directly on design assets so that it's clear which aspect of a design you're referring to. That's often a lot more effective than simply leaving a comment in an issue thread. And our accessibility testing category is now viable too, with new features that allow you to quickly determine the accessibility impact of pending code changes. When enabled, you'll see an accessibility report in the merge request widget that shows compliance with web content accessibility guidelines. That means you'll immediately know if your code introduced problems like color contrast ratio failures before your product change goes into production. Accessibility is a really important topic. Most importantly, because making products accessible creates a better experience for everyone, even users who happen to have disabilities that can make many digital project products almost impossible to use. But it's good for your business too when you build inclusive products that anyone can use. But that's not all. Now I'm going to turn things back over to Anoop to share a little more about a recent key focus area for our development team and upcoming plans for category maturity. Thank you, Christie. That is an amazing update. Thank you for sharing all the great work everyone's doing. I hope you all saw the emphasis on usability and security come through in that update. I'd like to share a bit more about the SAS first posture as well. Over the last several weeks, we have spent a lot of energy to improve SAS reliability and performance. SAS reliability picked up from a low of 99.3 in March to 99.84 in June. But we have more work to do. The team put in several measures to prevent runner abuse by crypto miners and optimize hundreds of SQL queries. Nearly the entire team refocused towards SAS first principles including establishing error budgets for the team and creating room for everyone to raise a flag as soon as they notice something underperforming and tooling to alert. Thank you for the Herculean efforts and we have already seen the impact that this makes. And to conclude, we continue to have an ambitious plan to help you succeed in building better software that is optimized to provide the intended value. We want over half our categories to be lovable in three years. We are expecting nearly 12 category movements to happen over the rest of the year. As always, thank you for believing in GitLab. Let's continue to innovate together. Have a nice day.