CI/CD Variable management

Instructions

Click to expand
  • Create a ♻ Retrospective Thread to capture future improvements to this issue template
  • Complete the sections in the issue template below
  • Link any relevant issues or research
  • Assign to your Manager
  • Assign to VP and EVP of Product for approval @sfwgitlab @adawar
  • Include VP of UX for visibility @clenneville
  • Record a walk-through of this issue (optional)
  • Make a copy of the Opportunity Lite Canvas Meeting - TEMPLATE and fill out the required points.
  • Schedule the review.
  • Once issue is approved, add the label ~oppty-lite::approved close issue and share in relevant slack channels
  • Follow up on the ♻ Retrospective Thread items and propose changes to this issue's template

Note: If issue is not approved, the issue can be closed without adding any labels.

Recorded Walk-Through

Why Canvas Lite?

I am using the Opportunity Canvas Lite format because variables are table stakes in any established CI/CD toolset the problem space is well known.

Customer Pain and Problem

  • Sasha - software developer
  • Devon - Devops engineer

JTBD

When architecting pipeline configuration, I want to be able to define variables so that it dynamically inherited across all hierarchies of a repository and pipelines in order to perform the complex operation without scripting those tasks to save time.

Problem Details

Variables are commonly used in CI/CD setups, extremely useful so users would not have to hardcode their pipelines, making pipelines and jobs agnostics to the environment, hardware, software, cloud providers and more... Variables could also affect the way pipeline runs, this is why it's extremely important for users to always know the value of their variables in any given time

Our users find variables scoping confusing the main areas where users are struggling with variables in GitLab are:

  1. Defining variables, which variable they should use (Pre-defined, UI, project lvl)? and how to define it (through the UI or the .gitlab-ci.yml)?
  2. Passing variables from and to a downstream/upstream pipeline.
  3. Using the variables that were inherited from/to downstream/upstream pipeline.

Proposed Solution

From our user research, we've learned that users would like to know what are the variables and values that are used in CI pipelines and jobs, by introducing a new feature that exposed variables in GitLab UI. we will alleviate the uncertainties around variable inheritance and precedence by displaying the available variables and value in a pipeline and allow users to manipulate its values before triggering a job.
The feature will be available as a premium feature for any project with multi project pipelines and as a free feature for projects without one.

The rationale as explained in #3179

  • We know that Multi-project pipelines are also useful for larger products that require cross-project interdependencies, like those with a microservices architecture.
  • We apply the same principle on pipeline graphs and our features by tier show that multi-project pipeline graphs are a top-cited driver for upgrades to Premium.

Based on buyer based tiering model and the lesson learned from multi-project pipeline graphs, this is a feature will be mainly used by teams and should be a Premium feature.

Before working on this projects variables restructure is needed and consistency when defining variables types

Business case

Variables is a table stakes solution, the total addressable market spans across all verify users that trigger pipeline (1.3M users) Variables have a rich feature set, however, with it we've accumulated many enhancement requests bugs where some restructure is needed

RICE

RICE score:

RICE score => 3.0(Reach) x 2(Impact) x 100(Confidence) / 12 (Effort) = 50

Reach

What count of users are you expecting to reach with this feature?

3.0% - Significant reach

Rationale

The reach is probably closer to the number of pipeline authoring users (200,000 unique users) and users that are debugging pipelines

Impact

Describe the impact this feature will have for those users.

Impact is high 2x

Rationale Variables are one of the popular categories we have on our team's backlog, it has also a rather large number of issues with high upvotes, over the last couple of years, many enhancement request had accumulated and we see some frustrated users that feels GitLab is ignoring them, working on improving this category not only improve the usability of this important feature, but would also improve the confidence users in our brand. Bridge pipeline become popular when working with monorepos and large pipelines, introducing a premium feature which solve the variables pains should encourage users to move from free to pay

Confidence

How confident are you in the problem and solution?

I have High confidence (100%)

Rationale
  1. The problems are clearly articulated in the issues and comments.
  2. Complete user research
  3. This is a popular feature in CI solution

Effort

How many person months do we estimate this will take to build?

12 PM

Rationale

There is a significant amount of work for improving variables.

In addition, we would like to build a new solution to expose variables in the UI.

Business Case Questions

  • Roughly what percent of those users would you expect to be Starter? Premium? Ultimate?
    • Same composite as Pipeline Authoring users
  • What other companies offer a feature like this?
    • Harness.io - provides an intuitive UI that show the used variables in a single job
  • When do you intend do deliver this feature?
    • FY23:Q3
  • What would happen if we waited to deliver this feature later than you have planned?
    • GitLab customers expect to get a reliable variable solution from GitLab, as of today, mainly in Multi project pipeline and Parent child pipeline variables consider to be unreliable. This can potentially lead to churn or at least lost revenue opportunities to other CI solutions.

Qualitative Evidence

Feature Maturity Plan

By offering the feature additions outlined in this Canvas Lite, we would expect to make the feature maturity:

  • Viable
  • Complete
  • Lovable

Feature Development Plan

  • What is the minimal change to make progress?
    • documentation update with more examples of variables inheritance in Multi project pipelines and Parent child pipelines
  • What are the next steps needed to address the problem?

Related Epics or Issues

Edited by Dov Hershkovitch