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.
This is the product direction for the Configure stage. This direction is aligned with the broader Deployment Direction.
The mission of the Configure stage is to make operators and platform engineers more productive and efficient in executing configuration and operational tasks in various deployment environments. The Configure stage is closely related to release management and continuous delivery and to the monitoring of environments. We do this by providing integrated workflows all within GitLab, a complete Value Stream Delivery Platform.
Our vision is that Platform and Ops teams will use GitLab as their primary day-to-day tool for collaboration with Software Developers and as a starting point for their job.
To the GitLab Community and customers,
TL;DR: We will continue maturing our GitOps and overall Kubernetes offering, the GitLab agent for Kubernetes. As part of this direction, we plan to sunset the certificate-based integration in GitLab 17.0 (around May 2024) if we manage to close all the blocking issues by mid-2023. Together with improving Kubernetes integrations, we want to improve the Kubernetes related delivery tooling of GitLab.
We planned very ambitiously for FY23 and we try to learn from it. We wanted to move the Kubernetes Management category to Complete in Q4. We failed this plan. Our plan for FY24 is to be near Complete maturity by the end of it. We realized that providing a mature, production-ready offering requires a much wider scope of features. We want to close this gap and be a mature solution around Q4FY24.
We want to remove the certificate-based Kubernetes integration in 17.0. This requires us to ship several features that currently block the removal and to improve the agent for Kubernetes to become a viable alternative for CI/CD and GitOps users as well. We supported the migration of several clusters to the agent in the past year. Given these migrations, we think that our CI/CD integration is good-enough and we want to primarily focus on improving the GitOps support of the agent. This would include Helm and Kustomize support and additions to scaling a single agent to support multiple manifest source repositories, multiple target clusters and more automation around access management to containers and charts within GitLab.
Besides the mentioned core GitOps features, we want to work on some delighters. We are integrating a resource overview into environment pages. Once this integration is ready, we want to build a generic Kubernetes dashboard into GitLab.
For the second half of the year, our plan is to turn our focus towards building out the delivery capabilities of GitLab. We imagine this with a Deployment management project and the GitLab Delivery framework. We plan to ship the first few iterations in FY24.
The above focus does not allow us to work on the Ingrastructure as Code offering. Thankfully, the Package:Package group took over the Terraform module registry and we have a growing community for the GitLab Terraform Provider that we finally managed to migrate to GitLab.
A more detailed plan is available in this merge request.
We build solutions targeting the following personas:
In keeping with our single application promise, we want GitLab to be a robust, best-of-breed tool for operators as much as it is for developers. Our vision is that operators will use GitLab as their main day-to-day tool for provisioning, configuring, testing, and decomissioning infrastructure.
GitLab's Configure stage is focused on providing enterprise ready configure capabilities to enable users to operate and deploy modern applications and cloud infrastructure. Given the area of our operation, our users typically assume a higher level buyer persona who decided to set up a dedicated Platform or Ops team. As a result, the majority of our features is either Premium or Ultimate.
However, since all application code needs a form of infrastructure, there will continue to be basic offering that targets Free users.
The tiering can have many forms, from feature availability to permissions management possibilities. We expect Ultimate features mostly around use cases that involve a level of reporting.
In many situations, our features might be considered to be building blocks for other product teams within GitLab. In these situations, the other teams decides about the pricing of the features they release.
We build products primarily for cloud-native companies who run their workloads in public or private clouds. Within the wide scope of possible technology integrations we picked Kubernetes and Terraform to integrate with first. We want to provide mature, market-leading offerings in these areas before starting new directions.
We operate in a space full of high-quality open source applications, and we expect GitLab to co-exist with tools which teams have already invested considerable time and money. As a result, we want to build on existing best practices and we want to provide an integrated experience with the preferred tools in the industry. Keeping up with the quickly changing nature of these tools is our primary challenge.
The technologies where we want to provide an outstanding, integrated experience with are
Given the wide breadth of the Configure group, we have to maintain a wide range of features. For this reason, our priorities extend the general GitLab prioritization framework.
security, bug:vulnerability or regression issue. We aim to prioritize related issues accordingly. Example: the cluster management project template ships Cert-Manager. An outdated Cert-Manager might be incompatible with the recent Kubernetes version is a regression, an outdated Cert-Manager with known CVEs might be a security issue.regression.To avoid much manual workaround keeping our systems up to date, we aim to automate most of the maintenance processes.
Our opportunities in the Configure stage are derived from the Ops Section opportunities. Namely:
This leads us to look into common workflows that we would like to support with a market-leading experience:
Other categories that fall under the Configure direction, but we are not actively investing in are
We aim to achieve these by focusing on the following principles.
We want to be good cloud-native citizens, build on top of and contribute back into open source tools. We believe in the power of the open source community and GitLab's everyone can contribute ethos.
We understand that Infrastructure as Code and cluster management at scale are complex, and best of breed technologies and much customization is required to fulfill advanced workflows. We want to support such advanced use cases. At the same time, we believe that many new users will become advanced users, and we can support them as well by providing production ready, turn-key solutions that incorporate the best practices followed by experts.
At GitLab we build a single application for the whole Dev(Sec)Ops pipeline. Our solutions should integrate deeply with and should support other GitLab features. We are paying special attention to security and collaboration oriented features.
While we want to provide supporting products for every company size, we expect enterprise users to have special needs that our integrated approach can serve well. Focusing on their use cases we can reduce their costs and enable faster go to market.
Our Key Performance Indicator for the Configure stage is the Configure SMAU (stage monthly active users).
See the corresponding Sisense dashboard (internal) for our primary KPIs.
At GitLab, one of our values is that everyone can contribute. If you're looking to get involved with features in the Configure area, there are a couple searches you can use to find issues to work on:
Contribute for Prize program is available on our Code Contributor Programs page.You can read more about our general contribution guidelines here.
Our vision for “Auto DevOps” is to leverage our single application to assist users in every phase of the development and delivery process, implementing automatic tasks that can be customized and refined to get the best fit for their needs. We believe that using Auto DevOps we simplify the adoption of a DevOps culture and best practices.
Learn more • Documentation • Direction
Creating integrated, easy to use workflows from source code management to Kubernetes based deployments and monitoring is a complex, time-consuming task. We target experienced users and provide solutions for production use cases. At the same time, we try to offer higher level abstractions and automation to support less experienced users too.
Learn more • Documentation • Direction
Deployments are becoming increasingly complex as we try to automate the propagation of a release from development towards production, and as new deployment strategies emerge. We believe that even business critical automation code should follow programming best practices, and this is rather hard with the current offering available in the industry. We want to make sure that our users can use GitLab for deployments on the long run. For this reason, we are starting a dedicated Deployment Management product direction at GitLab.
Learn more • Documentation • Direction
Infrastructure as code (IaC) is the practice of managing and provisioning infrastructure through machine-readable definition files, rather than manual hardware configuration or interactive configuration tools. The IT infrastructure managed by this comprises both physical equipment such as bare-metal servers as well as virtual machines and associated configuration resources. The definitions are stored in a version control system. IaC takes proven coding techniques and extends them to your infrastructure directly, effectively blurring the line between what is an application and what is the environment.
Today, we provide tight integration with Terraform.
Compute costs are a significant expenditure for many companies, whether they are in the cloud or on-premise. Managing these costs is an important function for many companies. We aim to provide easy-to-understand analysis of your infrastructure that could identify overprovisioned infrastructure (leading to waste), recommended changes, estimated costs, and automatic resizing.
In general, we follow the same prioritization guidelines as the product team at large. Issues will tend to flow from having no milestone, to being added to the backlog, to being added to this page and/or a specific milestone for delivery.
You can see our entire public backlog for Configure at this link; filtering by labels or milestones will allow you to explore. If you find something you're interested in, you're encouraged to jump into the conversation and participate. At GitLab, everyone can contribute!
Issues with the ~direction label have been flagged as being particularly
interesting, and are listed in the sections below.