Skip to content

Design: Private CI/CD Catalog MVC - Index page

Release notes

This issue focuses on scoping and refining an MVC proposal with the goal of dogfooding a private CI/CD Catalog.

Problem to solve

CI Templates live in separate distributed projects which are scattered across GitLab. Developers don't have an easy way to access, understand and use the CI templates to create pipelines. For in-depth context about the problem, see the epic description.

Intended users

JTBD

Once I have a stable development and operations organization, I want to author a CI pipeline so others in my team can leverage CI to increase the efficiency of their tasks.

User experience goal

  • When creating a pipeline I want to easily find a trusted pipeline template that matches my use case and get the guidance I need to use the template in my pipeline.
  • When scaling CI/CD processes in my organization I want to make the recommended workflows available to the projects in my organization so they can easily create a reliable, efficient and compliant pipeline.

UX definition of done

Click to expand

Problem Validation Phase

  • Problem is well understood and has been validated
  • JTBD is well understood and has been validated
  • PM has communicated the opportunity canvas to stable counterparts and group stakeholders, including the Product Designer and Product Design Manager

Design Phase

  • Document the JTBD and UX goal in the issue/epic description
  • Refine the user flows
  • Discuss and refine the scope of the iteration
  • Explore multiple different approaches as a team
  • Discuss the technical implications with Engineering 👈 We're here
    • Identify any potential cross-team dependencies and include the DRIs in the discussions
  • Identify a small set of options to validate
    • Document the user story(ies) for the MVC
    • Consider edge cases for each user story
    • Create prototypes or mockups for each user story
  • [-] Pajamas component lifecyle
    • [-] Identify component design or pattern update/creation
    • [-] Discuss the technical implications with Engineering
    • [-] Pajamas issue is created (within the scope of the MVC)
  • Update issues/epic descriptions
  • Proposed solution(s) identified and documented in the issue/epic description

Solution Validation Phase

  • Validate the solution to increase confidence in the proposed solution
  • Document the solution validation learnings
  • Product Designer has communicated the solution validation learnings to stable counterparts and group stakeholders, including the Product Design Manager
  • Update the MVC proposal with relevant insights from the solution validation
    • Design the mock-ups
    • Update issue/epic description with the new designs
    • Update the designs link in the proposal scope
    • Discuss the technical implications with Engineering

Proposal

Make it easy to share private pipeline components across the organization by adding them to the shared CI/CD Catalog page where components and their documentation are easy to find.

For details on our long-term vision see the epic and the architecture blueprint.

MVC Scope

  • A project will be used for storing the component. A project must be set to be pipeline components in the project settings, have a component configuration file and at least one release to be shared as a pipeline component in the CI/CD Catalog.
  • A release in the project creates an official component version. If the project is set to be used as a pipeline component in settings, the latest release will show up in the CI/CD catalog across the projects and groups in the organization.
  • The pipeline component can be used with commit SHA, so a release is not strictly necessary to use the component. A release is necessary for the component to show up in the CI/CD Catalog.
  • The pipeline component will be accessible for all users who have access to the same root namespace as the component project. For example, a developer in acme.com group will be able to see a pipeline component stored in acme.com/infra/ci/docker-component
  • An organization root namespace can only have one private pipeline components catalog.
  • A user can have access to multiple pipeline component catalogs if they have access to multiple organizations.
  • You can remove a specific version of the component by deleting a tag associated with a component version.
  • The component shows up in the catalog in the project main nav > CI/CD > CI/CD Catalog
  • 🔗 Figma

Further details

Permissions and Security

A pipeline component inside a root namespace (for example gitlab-org) will be accessible for all users who have at least developer access to the gitlab-org, as long as they also have access to the sub-group or project where the pipeline component is stored.

Users who have access to the general settings of the project can set the project to be used as a pipeline component.

Once that setting is on, anyone who can create a release in the project will be able to add new component versions to the CI/CD Catalog.

Documentation

Availability & Testing

Available Tier

  • Ultimate

Feature Usage Metrics

Tracked separately in #347178

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

What is the competitive advantage or differentiation for this feature?

Links / references

This 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.

Edited by Sunjung Park