Gitlab hero border pattern left svg Gitlab hero border pattern right svg

UX Vision: Package

Overview

Many projects depend on a growing number of packages that must be fetched from external sources with each build. This slows down build times and introduces availability issues into the supply chain. In addition, many of these external sources come from unknown and unverified providers, introducing potential security vulnerabilities. For organizations, this presents a critical problem. In order to address this need, we're focused on:

Our customer

The customer is anyone that is using GitLab to build, test and deploy software and is or would like to leverage a variety of package and/or image registries manage their dependencies. This sort of customer can be in any size or specific industry. A different customer is a large organization that utilizes several programming languages across teams and they would like to centralize all of their external dependencies in one location, GitLab.

Our user

We have different user types we consider in our experience design effort. Even when a user has the same title, their responsibilities may vary by organization size, department, org structure, and role. Here are some of the people we are serving:

Our UX Scorecards

Primary Jobs to be done

Enable and configure the container registry: When I first create a new project in GitLab, I want to be able to enable and configure the container registry, package registries and the dependency proxy, so that I can ensure my organisation can use GitLab in a scalable fashion.

Optimize registry storage: As part of regular project maintenance, I want the ability to optimize storage by expiring old images and artefacts and running garbage collection, so that I can optimize storage usage.

Use Ci pipelines to run and build docker images: When I commit code, I want my CI pipeline(s) to run and build a docker image, so that I can ensure that my integrations tests pass and that my team/org can deliver high-quality code.

Lookup specific image/tag/package: After I create a tag of a new image, I want to be able to find data related to that specific image, so that I can confirm it was built as expected and update my code as necessary.

Deleting a specific image/tag/package: As part of keeping my project organized, I need the ability to delete images/tags/packages that I am no longer using, so that I can maintain a well-groomed project.

Our team

Our team continues to grow. We currently have 3 members that contribute to Package UX efforts:

Our team meetings

Following in GitLab's tradition of async over sync, a majority of our communication is done through issues and merge requests. We do have a few regular synchronous meetings: