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.
| Stage | verify |
| Maturity | Minimal |
| Content Last Reviewed | 2024-08-25 |
Thanks for visiting this direction page on the Components catalog category at GitLab. This page belongs to the Pipeline Authoring Group in the Verify Stage and is maintained by Dov Hershkovitch. You can submit your feature requests using GitLab issue tracker.
We aim to foster a collaborative community of developers who can easily share, build, and maintain high-quality CI/CD configurations. By providing a platform that serves as a centralized hub for managing all DevOps-related assets within an organization, we aim to empower developers to focus on true innovation and unlock the full potential of the open-source ecosystem. Through our commitment to inclusivity, transparency, and accessibility, we strive to create a continuous learning and improvement culture where every community member can contribute.
DevOps is all about speed, it delivers value faster by shortening the software development life cycle. Organizations that want to accelerate their DevOps adoption need to set up a working pipeline so other teams can use it to automate their workflow. During the development of a pipeline configuration, engineers frequently encounter the following challenges:
While it is possible to solve each problem separately, GitLab believes that we need to solve those problems holistically by building a framework that contains tools that add functionality and improve your CI/CD workflow. We aspire to provide the best-in-class experience for building and maintaining CI/CD pipelines.
Our strategy is to provide an opinionated framework that:
We should adopt a bottom-up approach to construct this solution, starting with the smallest building blocks and gradually progressing upwards. By starting from the foundational elements and gradually building on them, we can create a robust and cohesive solution.
Now that we've moved the CI/CD catalog to GA our focus is the following
As we progress, these objectives highlight our commitment to delivering an upgraded catalog experience, surpassing user expectations and establishing a robust foundation for a thriving ecosystem
If you are interested in improving the Catalog, please checkout the feedback issue.
We aim to enhance our CI/CD catalog by introducing paid features tailored for enterprise customers, thereby delivering additional value to their operations.
In our effort to support all customer segments we would like to help our Self manage customers and customers in an air-gapped environment to easily consume components that exist today in our .com catalog. This approach aligns with our overarching goal of driving use case adoption, where every customer, regardless of their setup, can readily explore and implement additional functionalities from our platform.
A CI step is a minimum executable unit that the user configures; CI step runs in the context of a job, which enables the composability of jobs in your CI pipelines. A step is a type of component, which means it needs to be a first-class citizen of the Catalog, this translates to the fact that all the overarching features in the Catalog (Search, release, publish, inputs) need to be applied on CI step The CI Steps epic can be found here.
Our goal is to empower users with seamless control over component management across pipelines, ensuring optimal version control and project alignment. This addresses the challenge of users currently lacking visibility into component usage across various project pipelines. Our objective is to provide users with the capability to swiftly identify outdated versions and take prompt corrective actions as needed. This enhancement will foster an environment where users can efficiently manage and update components, promoting both version control precision and project alignment. More information can be found in this issue.
Inputs are the recommended way to pass any parameter to a component. It has multiple benefits over the usage of variables, and since its launch in 15.11, it has been widely adopted by our users and customers. This is why we decided to continue our investment in inputs and increase its scope and flexibility. More information can be found in this epic.
To increase customer confidence in components and the catalog, we aim to implement the following component designations:
Expanding the GitLab CI/CD catalog to accommodate multiple resource types will broaden its scope, enhance its utility, and cater to a wider range of development and deployment needs:
Introduce a service catalog to provide a centralized repository for all services within the organization. This service catalog will store key attributes, enabling engineers to:
We aim to empower central administrators to manage component creation, usage, and publication within their organizational catalog. We are committed to ensuring the publishing process seamlessly integrates with the organization's standards and existing workflows. Additionally, we want to enable platform administrators with the capabilities to secure and govern the catalog and component workflows. More information can be found in this issue.
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
The best way to understand how GitLab works is to use it for as much of your job as possible, this is why we practice dogfooding. We have recently begun collaborating with these internal teams in GitLab which expressed their desire to dogfood some of our features:
Notable competitors in this space are:
Watch this walkthrough video of the different contribution frameworks available by these competitors:
This section defines the terminology used throughout this project. With these terms we are only identifying abstract concepts, and they are subject to changes as we refine the design by discovering new insights: