Product Solutions Resources Partners Pricing Support Talk to an expert Get free trial Login GitLab Direction On this page Vision 3-year Direction Video 3-year Strategy Situation Strategic Challenges Product Strategy Product Strategy Learning Session Job to be Done DevOps Stages Personas Fiscal Year Product Investment Themes FY23 Product Investment Themes Improve Key workflow usability Extend our lead in CI/CD Data/ML driven insights for GitLab and customers FY22 Product Investment Themes Application Security Testing leadership Execution Plan for AST Leadership AST Leadership benefits for our customers and why we will win Adoption through usability Execution Plan for Adoption through Usability Usability benefits for our customers and why we will win Benefits to GitLab by focusing on usability Appeal of usability to us as product builders (Product, UX, Eng, Infra) GitLab-hosted First Why is this important? Our Execution Plan for GitLab-hosted first Mitigating low-end disruption Maturity Scope Quarterly Objectives and Key Results (OKRs) Your contributions How we plan releases Previous releases Upcoming releases Mobile strategy Mobile focus areas Mobile direction ML/AI at GitLab Cross-Stage Efforts Existing Cross-Stage Capabilities Planned Cross-Stage Improvements Single-Engineer Groups Footnotes You are here: GitLab Direction The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc. Vision GitLab’s 10-year product vision is inspired by our mission to make it so that everyone can contribute. Today GitLab is the DevOps Platform, empowering organizations to maximize the overall return on software development by delivering software faster and efficiently, while strengthening security and compliance. We believe our DevOps platform vision is shared by market analysts who have coined it the Value Stream Delivery Platform market. Over the next ten years, our vision is to expand GitLab in the following ways. First, we expect to continue rapidly maturing our DevOps platform so that GitLab is able to replace any DevOps point solution. To replace any DevOps solution will require most of our categories to be lovable, which is likely a 10 year journey. To ensure rapid progress, we have a 3-year goal to have 50% of our categories at lovable maturity by the end of 2023, and this three year product strategy articulates our current focus. Once we achieve that goal, there will still be more work to do, but having half our categories lovable will mean most DevOps tools are replaceable by GitLab. Second, we expect GitLab to expand its DevOps platform to provide similar support for ModelOps and DataOps. Over time, data and machine learning/AI models will increasingly power software experiences. Our customers will need an ability to manage data and its associated ML/AI models in a similar fashion to software projects. We endeavor to support data scientists and data engineers just as we support software developers today, by enabling rapid development, testing, production deployment, and monitoring of data models. We would also expect to automate handling of product usage data collection, GDPR compliance of data under management, cookie and privacy management, experimentation tools, A/B testing, etc. Third, we expect GitLab to become a creation platform for all digital content. This will require us to expand beyond traditional software development. Possible new digital content creation formats we could support include low code/no code development, design creation, and other creative media like music and movies. It would also likely require enhanced content management to better enable customers to create great digital experiences for their users. We execute on our vision rapidly and efficiently by leveraging the best practices of 100,000 organizations co-developing the DevOps platform of their dreams. We take a seed then nurture approach to maturing our product surface area over time, all the while, focusing on customer results. We leverage sensing mechanisms and product usage data to make decisions about where to increase or decrease investment. You can read more about the principles that guide our prioritization and product thinking in our product handbook. 3-year Direction Video The following 6-minute video gives a quick overview into where the GitLab product is headed the next few years. 3-year Strategy Situation GitLab competes in a large market space, with a TAM estimated at ~$18B in 2024. GitLab has recently surpassed the $150M ARR milestone, with unusually high revenue growth and retention rates. GitLab is uniquely positioned in the market with a vision to offer a single application for the entire DevOps lifecycle. GitLab competes across numerous market segments and aims to deliver value in 80+ market categories. GitLab’s product vision is uniquely ambitious, as we were the first DevOps player to take a single application approach. From idea to production, GitLab helps teams improve cycle time from weeks to minutes, reduce development process costs, and enable a faster time to market while increasing developer productivity. With software “eating the world,” this is widely viewed as a mission-critical value proposition for customers. We also have a number of tailwinds in the form of cloud adoption, Kubernetes adoption, and DevOps tool consolidation, which are helping fuel our rapid growth. Finally, GitLab has an open source community and distribution model, which has exposed the value of GitLab to millions of developers and has sped up the maturation of our product through more than 200 monthly improvements to the GitLab codebase from our users. Strategic Challenges Tension between Breadth and Depth: GitLab’s ambitious single application product vision means we need to build out feature function value across a very large surface area. Our challenge is to drive the right balance between breadth and depth in our product experience. In recent years, we have optimized for breadth. To win and retain more sophisticated enterprise customers, we need to effectively seed then nurture in areas of the product that generate usage and revenue. With so much product surface area to deliver in a single application experience, it is a big UX challenge to keep the experience simple, consistent, and seamless between DevOps phases. GitLab.com and Self-Managed: Another challenge we face is the balance between our self-managed and GitLab.com offerings. GitLab's early paying customers were more interested in self-managed, and the majority of our customers use this offering today. As a result, we focused heavily on delivering a great self-managed customer experience. However, as the market shifts toward cloud adoption, we are seeing an increasing demand for our GitLab.com offering. We now need to rapidly meet the same enterprise-grade security, reliability, and performance expectations our paying customers have come to expect from self-managed in our SaaS (.com offering). Wide Customer Profile: We also serve a wide range of customers, from individual contributor developers to large enterprises, across all vertical markets. This range of deployment options and customer sizes makes our business complex and makes it hard to optimize the customer experience for all customer sizes. Over the past few years, we have prioritized enabling our direct sales channel, but in the process have not focused enough on great customer experiences around self-service purchase workflows, onboarding, and cross-stage adoption. Competition: Finally, we have formidable competition from much larger companies, including Microsoft, Atlassian, and Synopsys to name a few. Microsoft is starting to mimic our single application positioning, and while behind us in the journey, have substantial resources to dedicate to competing with GitLab. Product Strategy Focus on increasing Stages per Organization (SpO): There is a strong correlation between the number of stages customers use and their propensity to upgrade to a paid package. In fact, adding a stage triples conversion! Each product group should be laser focused on driving adoption and regular usage of their respective stages, as it should lead to higher Net ARR, reduced churn, and higher customer satisfaction. As outlined in this user journey, the most important additional stages for customers to adopt are Create to Verify and Verify to Release, as each of these adoption steps open up three additional stages to users. Harness the unique power of a single application: GitLab’s primary point of differentiation is our single application approach. As we continue to drive value in any given stage or category, our first instinct should be to connect that feature or product experience to other parts of the GitLab product. These cross-stage connections will drive differentiated customer value and will be impossible for point product competitors to imitate. Recognizing this opportunity, we have grown our R&D organization significantly over the past two years, and plan to invest an outsized amount on R&D for the next 2-3 years to extend our lead in executing against the single application product vision. Increase wider-community contributions: To achieve this ambitious vision more quickly, we will leverage our powerful open source community. Each stage should have a clear strategy for tiering the value of the stage. When stages are early in maturity, we will bias toward including as much functionality in our Core open source version as possible, to drive more rapid adoption and greater community contributions, which will help us mature new stages faster. Once stage adoption is achieved, we can then layer on additional value in paid tiers to encourage upgrades. Make our core journey categories lovable: We want to ensure the core product usage experience is great, which will lead to more paying customers and improved customer retention. We intend to maintain our market-leading depth in stages with lovable categories, which currently are Verify (Continuous Integration) and Create (Source Code Management and Code Review). Beyond that, we will endeavor to rapidly mature our offering to lovable in Plan (3rd most used stage), Release (4th most used stage), and Secure (important element of our Ultimate tier). Our goal is to have 50% of our categories at lovable maturity by the end of 2023. GitLab-hosted first: Most customers don't want to run GitLab themselves (self-managed), so we should build out the offerings where we do it for them (GitLab-hosted). GitLab-hosted includes our SaaS (GitLab.com), any single-tenant offerings, and other GitLab hosted services that self-managed installations can use. Our customer and revenue growth rate for our SaaS offering is faster than our self-managed offering. To meet growing customer demand, our SaaS offering needs to have enterprise-grade security, availability, and performance. We must also ensure feature parity between self-managed and SaaS and that customers have an easy migration path from self-managed to SaaS. Going forward, all new features should be available on SaaS when they are available on self-managed, if not before. We will also begin offering GitLab-hosted services to self-managed customers to provide additional value that may not be feasible to deliver in a self-managed environment, e.g. automated cloud backups. Finally, we expect to offer different GitLab-hosted deployment options for single tenant customers and specific geographic regions to meet the regulatory, security and data residency requirements of various customer segments. Product Strategy Learning Session GitLab CEO and Product leadership discuss the Product Strategy in detail during a CEO Handbook Learning Session. Job to be Done Every product should have a single job that it strives to do. At GitLab we use the Jobs to be Done (JTBD) framework. A JTBD is the reason why people employ a product. GitLab's overarching Job to be Done is: When we are building software as a team, we want to get from ideas to production with quality, reliability, and security quickly and within budget, so that our organization can deliver promised value and achieve our business outcomes. DevOps Stages MANAGE SECURE PLAN RELEASE PACKAGE DEV OPS CREATE VERIFY CONFIGURE PROTECT MONITOR .a {font: bold 24px Source Sans Pro,sans-serif;fill: white;} .b {font: bold 60px Source Sans Pro,sans-serif;fill: black;} DevOps is a broad space with a lot of complexity. To manage this within GitLab, we break down the DevOps lifecycle into a few different sections, each with its own direction page you can review. Dev Section Direction - Includes the Manage, Plan, Create, and Ecosystem stages Ops Section Direction - Includes the Deployment Direction and the Verify, Package, Release, Configure, and Monitor stages Sec Section Direction - Includes the Secure and Protect stages ModelOps Section Direction - Includes the ModelOps stage, which includes the Applied Machine Learning, Anti-Abuse, MLOps, and DataOps groups Growth Section Direction - Includes the Growth stage, which includes the Activation, Conversion, Expansion, Adoption, and Product Intelligence groups Fulfillment Section Direction - Includes the Fulfillment stage, which includes the Purchase, License, and Utilization groups Enablement Section Direction - Includes the Enablement stage, which includes the Distribution:Build, Distribution:Deploy, Geo, Memory, Global Search, Database, and Sharding groups SaaS Platforms Section Direction - Includes the SaaS Platforms stage, which includes the Delivery, Scalability, and Project Horse groups Single-Engineer Groups Section Direction - Includes the Mobile and Deploy stages We are investing in the following manner across each stage. Personas Personas are the people we design for. We’ve started down the path of having developers, security professionals, and operations professionals as first-class citizens; letting each person have a unique experience tailored to their needs. We want GitLab to be the main interface for all of these people. Show up at work, start your day, and load up GitLab. And that’s already happening. But there are a lot of other roles involved with the development and delivery of software. That is the ultimate GitLab goal - where everyone involved with software development and delivery uses a single application so they are on the same page with the rest of their team. We are rapidly expanding our user experience for Designers, Compliance Managers, Product Managers, and Release Managers. We’ll also be expanding to the business side, with Executive visibility and reporting. While we’re still calling it DevOps, we’re really expanding the definition of DevOps and delivering it all as a single application. Fiscal Year Product Investment Themes Every year at GitLab, we choose some specific areas of emphasis to help guide the teams on the directional themes that we want to accentuate in our product. This section is used to highlight that emphasis. It is not a comprehensive list of everything we plan to do this year. Direction for each stage and category can be found at the respective direction pages. We are not asking the teams to deviate from their core mission. Many teams will see themselves contributing to these areas of emphasis directly. The other teams will continue to execute on their mission - that is also important. The themes are to help facilitate cross-team collaboration when invariably teams working on the 1-year themes may need to collaborate with others. Our guidance is: if any team approaches you to prioritize something that is thematic for this year, consider that as a higher priority than you would normally - as it is in service of the broader product-wide goal that we, as a company, have deemed important to accomplish this year. FY23 Product Investment Themes For FY23, the 3 key product themes we are focused on are: Improve Key workflow usability Performance Indicator: UX Scorecard improvements for key workflows In FY22 we had a broad effort to improve usability. We accomplished a lot. We also learned that we need a concerted effort to improve key workflows as they are often complex, require cross-functional alignment and drive a majority of usability feedback about the product. For FY23 we aim to provide: Excellent enterprise planning workflows Intuitive Settings & Navigation Onboarding/learnability to drive multi-stage adoption A code review experience that is more efficient and intuitive for both reviewers and authors. Key outcomes include less average time spent per line of change, and fewer review cycles on average. Extend our lead in CI/CD Performance Indicator: Percentage increase in Y/Y growth of Ops Section CMAU and Ops Section Paid CMAU CI is one of the first use cases customers experience that provides them value and an appreciation of the potential of a single application for the DevOps lifecycle. For FY23 we want to make sure we extend our lead in CI and also make it equally easy and seamless to enable CD use cases. For FY23 we aim to: Deliver on the new Deployment direction Drive Package Stage maturity and adoption Runner fleet management and cloud-first runners Data/ML driven insights for GitLab and customers Performance Indicators: Percentage of accounts that have data to inform their adoption Percentage of groups that have a full funnel for their adoption cycles ModelOps Stage MAU Human toil reduction around abuse efforts Absolute reduction in dollar cost of abuse on the platform Optimize GMAU Growth and its qualitative impact on sales As software development itself transforms to include Machine Learning and models, we aim to make it easier for GitLab users to embrace these technologies and combine them with the best practices of DevOps. In addition we want to use insights from Data and ML to, in a privacy respecting manner, improve our own decision making capabilities - ranging from product investment decisions, to helping our customers derive maximum value from GitLab capabilities, to driving an efficient and predictable business. We aim to: Deliver ModelOps capabilities Enhance anti-abuse systems Provide Executive/Director persona dashboards to help executives see the value of the single application Use Data insights to inform product improvements decisions Use Data insights to help customers derive maximum value from the single application FY22 Product Investment Themes For FY22, the 3 key product themes we are focused on are: Application Security Testing leadership Performance Indicator: Total user growth for Ultimate As part of our land-and-expand strategy, we consider Application Security Testing (AST) a critical land play after SCM and CI. We will take a leadership position within the AST market as we build on our FY21 success and extend the AST offering to meet the most demanding customer requirements. Execution Plan for AST Leadership We will establish a leadership position within the Application Security Testing (AST) market by moving Static Analysis (SAST), Dynamic Analysis (DAST), and Dependency Scanning categories to Complete maturity, as well as moving Vulnerability Management to Viable maturity. In addition, we will introduce a Fuzz Testing category and bring it to Viable maturity. AST Leadership benefits for our customers and why we will win Our single application for the DevSecOps lifecycle allows Developers and Security professionals to collaborate in ways natural to them, but with unprecedented effectiveness. Developers can find vulnerabilities at the time of code commit, making it easier to fix them without context switching. This leads to acceptance and adoption by developers. In addition, Security professionals gain visibility into vulnerabilities at the time the code is committed and when modifications, approvals, and exceptions are made. They can also enforce security policies in the merge request flow. The end result is that organizations that adopt GitLab benefit by: Lower cost of remediation Naturally shift security left Broader and deeper testing than before with new scan types Support for more languages and frameworks Ability to find unknown vulnerabilities in the projects A systematic method towards better security and risk visibility across their organization Ability to protect Kubernetes deployments Adoption through usability Performance Indicator: Increase in Predicted TMAU The key to unlocking the power of a single application is to have customers experience the value of multiple stages working together. We believe that improving usability is our primary path to unlocking multi-stage adoption. Execution Plan for Adoption through Usability We will focus on making features more discoverable, working by default, and usable. If we can do this successfully, new users will be more likely to buy, current customers will be more likely to add seats and uptier, and the customers will maximize the benefit they can extract from using GitLab. Key areas of focus: Convention over Configuration Configuration Principles, when required Simplifying Projects and Groups Principled adherence to our established knowledge architecture Researching and improving key cross-stage moments Quarterly OKRs to drive improvements in the key usability themes Redesigning Auto DevOps to enable easy stage onboardings Integrating Incidents into common workflows Usability benefits for our customers and why we will win A single application for the DevOps vision isn’t new. What is new is our approach to it. Others who attempt this try to stitch together point products after the fact (either through M&A or a “solution kit” exercise). The key difference between stitching point products together vs a single application comes down to seamless interconnections between the stages, so that the product effortlessly moves from one job to be done to the next. All personas feel like they have an ability to connect and collaborate with each other in the same space and don’t have to maintain separate integrations and data systems simply to do their job. Benefits to GitLab by focusing on usability McKinsey conducted a five-year study on the business value of design which showed top-quartile companies increased their revenues and total returns to shareholders substantially faster than their industry counterparts did over a five-year period. McKinsey found that top-quartile companies experienced 32 percentage points higher revenue growth and 56 percentage points higher TRS growth for the period as a whole. Appeal of usability to us as product builders (Product, UX, Eng, Infra) Many users of GitLab start and end their working days with GitLab. They spend a lot of time with our tools to get their work done. If we make the experience delightful, we have a meaningful opportunity to enhance their quality of life. It's a win, win, win. Win for our customers, win for GitLab, and a sense of pride/win for us as builders. GitLab-hosted First Primary Leading Performance Indicator: Meet GitLab.com availability target Secondary Lagging Performance Indicator: Increase in Paid GMAU for gitlab.com_ GitLab-hosted First does not mean GitLab-hosted only. We are committed to our Self-managed as well as GitLab-hosted customers. Our software architecture has a single unified codebase that allows us to serve both deployment models without the additional burden other vendors may have because they chose to create different software stacks for hosted and Self-managed offerings. This year, we place emphasis on strengthening our GitLab-hosted offering by delivering the most critical requirements for GitLab-hosted customers and driving towards feature parity with our market leading self-managed offering. Why is this important? We have north of 800K SaaS MAU. These users deserve and expect a reliable, available, and performant experience. IDC projects that SaaS-based delivery of DevOps tools (26.4% 2019-2024 CAGR) will overtake on-premise/other software (7.1% 2019-2024 CAGR) by 2022.1 This represents a large and urgent opportunity for GitLab, which has an estimated 9% usage-share of the cloud hosted Git repository market, based on Bitrise repository counts, compared to our 67% usage-share of self-managed Git solutions Additionally, IDC predicts that the market for SaaS-based DevOps tools (38% of the market in 2019) will overtake on-premise/other software (62%) by 2022 and account for $10.3B in revenue (or 58% of DevOps software tools market) by 2024.1 As a result, over this time period we expect to see an increase in existing self-managed users migrating to GitLab.com, as well as the majority of prospective customers preferring SaaS over self-managed deployment. We have two-thirds of the usage-share of self-managed Git solutions. We will provide a compelling onboarding experience to ensure that we are able to serve our customers on SaaS just like we do on Self-managed. Our Execution Plan for GitLab-hosted first First and foremost, we want to deliver a reliable, highly available, and performant GitLab experience that meets our defined KPI targets. In addition, as we develop features and capabilities, we will provide them on GitLab-hosted as well as Self-managed. If faced with a choice to deliver it on one deployment method first - for example, Self-managed first, GitLab-hosted next or vice versa - we will choose GitLab-hosted First and Self-managed next. Starting in FY22, we added a new GitLab-hosted parity product principle to help clarify our focus. Our focus will be on: Availability and performance Enterprise-grade security and compliance Improving usability for admins Improve our product intelligence capabilities so we can better understand SaaS usage GitLab-hosted parity Simplify Projects and Groups Mitigating low-end disruption GitLab is not immune to disruption. In some ways, it is a sign of success that GitLab is now at a scale where we have to think about low-end disruption. Arguably, a few years ago, GitLab was a low-end disruptor. Clayton Christensen defines low-end-disruption as follows: Low-end disruption refers to businesses that come in at the bottom of the market and serve customers in a way that is "good enough." These are generally the lower profit markets for the incumbent and thus, when these new businesses enter, the incumbents move further "upstream." In other words, they put their focus on where the greater profit margins are. Our perspective is that low-end disruption is an additional and critical sensing mechanism. This is especially true for the DevOps market. We look at the following attributes to figure out if a low-end disruption has anything close to potential product-market resonance. This list is an adaptation of the Product Zeitgeist Fit. Builder Enthusiasm: Are the most talented, hardest working, or most-in-demand people - the engineers, the developers - so intrigued by the approach that they are working on it, excited by it, and trying to make it a thing? If that is the case, then there is a good chance that they will eventually make it happen, moving beyond the fringes to the mainstream. Number of stars, forks, and contributions in the repo are some metrics to look for here. Despite Test: When people are using a product despite the fact that it’s not the best thing out there, or, in some cases, that it’s straight-up terrible, it’s a great sign. It shows that the product has a line into something emotional, not solely functional. Wanted, not just needed. In the early days, these products can often feel misunderstood or controversial. At first blush, the conceit may even raise a few eyebrows. But to the people who have been working on those products, they’re so clearly elegant, if temporarily imperfect, solutions to big and important problems that they seem almost obvious once they recognize it. Google Trends and posts on Hacker News are some things to monitor here. T-shirt test: If people with no connection to the company are wearing their t-shirts or putting their stickers on their laptops or wearing their socks, that desire to associate with the idea indicates as much a movement as a product. A reason low-end disruptors are able to enter the market is that the feature-absorption by users is lower than the feature-velocity of the established vendor. To address this we are focused on a working-by-default configuration principle. Maturity As we add new categories and stages to GitLab, some areas of the product will be deeper and more mature than others. We publish a list of the categories, what we think their maturity levels are, and our plans to improve on our maturity page. We strive to be the best product in the market and to be truly lovable. As the market, customer needs, competitive landscape, and technology change, we should expect our maturities to also change, including changing to a lower maturity rating. By embracing a focus on improvement and low level of shame, we encourage moving a maturity down. This is a strong indicator that we are realists about our product with an eye on achieving the best results for our customers. Scope We try to prevent maintaining functionality that is language or platform specific, because they slow down our ability to get results. Examples of how we handle it instead are: We don't make native mobile clients. Instead, we make sure our mobile web pages are great. We don't make native clients for desktop operating systems. People can use Tower and, for example, GitLab was the first to have merge conflict resolution in our web applications. For language translations, we rely on the wider community. For Static Application Security Testing we rely on open source security scanners. For code navigation, we're hesitant to introduce navigation improvements that only work for a subset of languages. For code quality, we reuse Code Climate Engines. For building and testing with Auto DevOps, we use Heroku Buildpacks. Outside our scope are Kubernetes and everything it depends on: Network (fabric) Flannel, Openflow, VMware NSX, Cisco ACI Proxy (layer 7) Envoy, nginx, HAProxy, traefik Ingress (north/south) Contour, Ambassador, Service mesh (east/west) Istio, Linkerd Container Scheduler we mainly focus on Kubernetes, other container schedulers are: CloudFoundry, OpenStack, OpenShift, Mesos DCOS, Docker Swarm, Atlas/Terraform, Nomad, Deis, Convox, Flynn, Tutum, GiantSwarm, Rancher Package manager Helm, ksonnet Operating System Ubuntu, CentOS, RHEL, CoreOS, Alpine Linux During a presentation of Kubernetes, Brendan Burns talks about the four Ops layers at the 2:00 mark: Application Ops Cluster Ops Kernel/OS Ops Hardware Ops GitLab helps you mainly with application ops. And where needed, we also allow you to monitor clusters and link them to application environments. But we intend to use vanilla Kubernetes, instead of something specific to GitLab. Also outside our scope are products that are not specific to developing, securing, or operating applications and digital products. Identity management: Okta and Duo, you use this mainly with SaaS applications you don't develop, secure, or operate. SaaS integration: Zapier and IFTTT Ecommerce: Shopify In scope are things that are not mainly for SaaS applications: Network security, since it overlaps with application security to some extent. Security information and event management (SIEM), since that measures applications and network. Office productivity applications, since "We believe that all digital products should be open to contributions, from legal documents to movie scripts and from websites to chip designs" We expect GitLab to continue to grow, and we have several ideas for possible future stages Quarterly Objectives and Key Results (OKRs) To make sure our goals are clearly defined and aligned throughout the organization, we make use of OKRs (Objectives and Key Results). Our quarterly Objectives and Key Results are publicly viewable. Your contributions GitLab's direction is determined by GitLab the company and the code that is sent by our contributors. We continually merge code to be released in the next version. Contributing is the best way to get a feature you want included. On our issue tracker for CE and EE, many requests are made for features and changes to GitLab. Issues with the Accepting Merge Requests label are pre-approved as something we're willing to add to GitLab. Of course, before any code is merged it still has to meet our contribution acceptance criteria. How we plan releases At GitLab, we strive to be ambitious, maintain a strong sense of urgency, and set aspirational targets with every release. The direction items we highlight in our kickoff are a reflection of this ambitious planning. When it comes to execution, we aim for velocity over predictability. This way, we optimize our planning time to focus on the top of the queue and deliver things fast. We schedule 100% of what we can accomplish based on past Development Department merge request rate and availability factors (vacation, contribute, etc.). See our product handbook on how we prioritize. Previous releases On our releases page, you can find an overview of the most important features of recent releases and links to the blog posts for each release. Upcoming releases GitLab releases a new version every single month on the 22nd. You can find the major planned features for upcoming releases on our upcoming releases page or see the upcoming features for paid tiers. Note that we often move things around, do things that are not listed, and cancel things that are listed. Mobile strategy Developing and delivering mobile apps with GitLab is a critical capability. Many technology companies are now managing a fleet of mobile applications, and being able to effectively build, package, test, and deploy this code in an efficient, effective way is a competitive advantage that cannot be understated. GitLab is taking improvements in this area seriously, with a unified vision across several of our DevOps stages. Mobile focus areas There are several stages involved in delivering a comprehensive, quality mobile development experience at GitLab. These include, but are not necessarily limited to the following: Manage: Comprehensive templates to get started quickly Create: Web IDE features that allow you to easily manage the kinds of code and artifacts you work with during mobile development Verify: Runners for macOS, Linux-based builds for iOS Package: Build archives for mobile applications Release: Review Apps for mobile development, code signing, and publishing workflows to TestFlight or other distribution models Secure: Security scanning built directly into CI/CD pipelines, supporting a variety of mobile coding languages Mobile direction We have more details about our plans on the Mobile direction page. Some of our older thoughts are collected in the original epic. ML/AI at GitLab Right now, GitLab doesn't use any ML/AI technologies in production features, but we expect to use them in the near future for several types of problems. This is the focus of our new Learn stage. Cross-Stage Efforts GitLab consistently strives to deliver a cohesive experience that enables workflows that span the DevOps loop. We have a number of existing capabilities and planned improvements that do just that: Existing Cross-Stage Capabilities Define your CI/CD pipelines directly in your repository Releases associated to milestones Generate a Release from .gitlab-ci.yml Create a GitLab or Jira issue from a vulnerability Create a merge request from an issue Measure DevOps success via the DORA metrics Create Incidents as an Issue Type Connect your clusters via the CI/CD Tunnel Relate issues and Feature Flags Run multiple pipelines and project dependencies with multi-project pipelines Enable concurrency control during deployments with Resource Groups Associate job artifacts, or a generic package to a Release Planned Cross-Stage Improvements Improve Pipeline Authoring's Experience with Compliance Pipelines Update Issues based on Cross-Stage activity CI/CD Tracing with OpenTelemetry Alert on CI/CD pipeline events Single-Engineer Groups We set big hairy audacious goals that may take a long time to deliver. Because of this, we leverage Single-Engineer Groups to adequately explore a new space, build rapid Interactions, and grow a community around the problem space. Below is a list of areas where we are putting some longer term bets. Mailinglist functionality Make the development experience on Kubernetes great Automate the transformation of a codebase into a build Five Minute Production MinIO Apache2 fork Salesforce development Figma Alternative Server Runtime Github1s and git peek Low-code offering Webflow offering Database for Auto DevOps Auto suggest text SIEM Exclusively use Service Desk Marketing insights Other CI platforms (GPU, ARM, TPU, DPU) Quick testing feedback Review apps as a service (without own Kubernetes Cluster) Warn about merge conflict immediately when you edit/commit Native OKRs 1-1 and coaching platform Handbook Implement cross-server (federated) merge requests Rebuild/update all containers Premium Make native applications for iOS and Android Run tests in the cloud, pre-commit from a client Premium Copy-on-write fuse filesystem Autocommit using auto-assigned approvers Suggest edits to fix common errors detected by CI Code to issue audit Clone MR IDE / editor with a local editor via mirroring / sync Render like BigPipe for better perceived performance Real-time Editing of Issue Descriptions (REID) Failure Injection Testing (FIT) or Chaos as part of operations features Premium PeopleOps tool - Talent management (recruiting in particular) Speed up CI with incremental builds and tests (Bazel) Footnotes IDC, Worldwide DevOps Software Tools Forecast, 2020–2024, Doc # US45188520, July 2020 Twitter Facebook YouTube LinkedIn Why GitLab? Product Solutions Services DevOps tools Is it any good? Releases Pricing Get started Resources All resources All-Remote Blog Newsletter Events Webcasts Topics Training Docs Developer Portal Install Community Customers Contribute Community Programs Direction Technology Partners Channel Partners Open Source Partners GitLab for Open Source GitLab for Education GitLab for Startups Shop Community Forum Support Get help Contact Sales Contact Support Support options Status Customers Portal Company About What is GitLab? Jobs Culture Leadership Team Press Investor Relations Analysts Handbook Security Contact Terms Privacy Cookie Preferences Trademark Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license View page source — Edit in Web IDE — please contribute. © 2021 GitLab B.V. This website uses cookies We use cookies to make our websites and services operate correctly, to understand how visitors engage with us and to improve our product and marketing efforts. See our cookie policy for more information.Cookie Policy Cookies Settings Accept All Cookies