The following page contains 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.
The mission of the Configure stage is to make developers and operators more productive and efficient in executing configuration and operational tasks for cloud-native applications and infrastructure. The Configure stage is closely related release management and continuous delivery. We do this by providing integrated workflows all within GitLab, a complete Value Stream Delivery Platform.
Our vision is that DevOps teams will use GitLab as their primary day-to-day tool as it will provide first-class operator support.
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. However, since all application code needs a form of infrastructure, there will continue to be basic offering that targets Core/Free users.
Every customer, including individual developers, need to be able to configure and deploy infrastructure. As such, integration with Terraform for Infrastructure as code is available to all GitLab users.
Cloud native development is container based. More and more are using Kubernetes for container orchestration, even on personal projects. As part of the GitLab Core offering, Kubernetes management is also available with a limit to manage a single cluster.
Individual teams are more likely to operate more than one single cluster. The limits on cluster management is increased to 5 clusters.
For medium sized organizations, limits on clusters under management are lifted so that teams can use GitLab GitOps without restriction. In addition as the infrastructure complexities increase, as part of our policy management capability, Premium users can see and visualize policy violations to provide safeguards to teams operating quickly.
For enterprises, when the complexity in infrastructure becomes unmanageable manually, Configure will provide more insights and visualization into various infrastructure elements. This includes cluster cost management and the ability to visualize the whole infrastructure.
We build products primarily for an 8 team SaaS product company, likely with a serverless or docker based architecture. In the latter case, we assume it's deployed either to Kubernetes or with Terraform to anything that Terraform supports.
We understand GitLab will play side-by-side with existing tools which teams have already invested considerable time and money. As a result, we will extend GitLab's Configure features to provide an outstanding, 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
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).
| Configure SMAU is a proxy metric of all the active project users for any projects with a cluster attached. |
See the corresponding Sisense dashboard (internal) for our primary KPIs.
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.
With the dramatic increase in the number of projects being managed by software teams (especially with the rise of micro-services), it's no longer enough to just craft your code. In addition, you must consider all of the other aspects that will make your project successful, such as tests, quality, security, logging, monitoring, etc. It's no longer acceptable to add these things only when they are needed, or when the project becomes popular, or when there's a problem to address; on the contrary, all of these things should be available at inception.
That's why we created Auto DevOps. We also made it composable so you can pick and choose which stages to use our default templates in. The relevant Auto DevOps components for each GitLab stage are maintained by the product groups in those stages. For example the Auto Deploy jobs are maintained by the Progressive Delivery group and the Auto SAST, Dependency Scanning, License Compliance, Container Scanning and DAST jobs are maintained by the relevant Secure groups.
Watch the video explaining our vision on Auto DevOps
Learn more • Documentation • Direction
Configuring and managing your Kubernetes clusters can be a complex, time-consuming task. We aim to provide a simple way for users to configure their clusters within GitLab; tasks such as scaling, adding, and deleting clusters become simple, single-click events.
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.
Our focus will be to provide tight integration with best of breed IaC tools, such that all infrastructure related workflows in GitLab are well supported. Our initial focus will be on 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.
Taking full advantage of the power of the cloud computing model and container orchestration, cloud native is an innovative way to build and run applications. A big part of our cloud native strategy is around serverless. Serverless computing provides an easy way to build highly scalable applications and services, eliminating the pains of provisioning & maintaining.
Learn more • Documentation • Direction
Incident Management will
allow operators to have real-time view into the happenings of their systems.
Building upon this concept, we envision rendering of runbook inside of GitLab as
interactive documents for operators which in turn could trigger automation
defined in gitlab-ci.yml.
The next generation of our ChatOps implementation will allow users to have a dedicated interface to configure, invoke, and audit ChatOps actions, doing it in a secure way through RBAC.
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.
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.
There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.
Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!
