The goal of this page is to create, share and iterate on the Jobs to be Done (JTBD) and their corresponding job statements for the Package stage. Our goal is to utilize the JTBD framework to better understand our buyers' and users' needs.
Utilize JTBD and job statements to:
When my organization is producing and storing packages and/or images, I need the Package and Container Registry to function seamlessly and reliably, so our developers have a consistently stable product development experience.
|When my code changes are ready to be merged, I need my Ci/CD solution to automatically build my package and deploy it to the correct registry, so I can efficiently deliver an improved experience to the customer.||Researched||Issue|
|When I need to add a new package to my codebase, I need an easy way to know what version to use, so I can deliver quality without worrying about dependency related regressions due to versioning.||Researched||Issue|
|When I am actively working on improving my organization's code base, I need a smooth and consistent authentication experience with regard to the registries, so I can focus my attention on delivering value to our customers.||Researched||Issue|
|When I am updating a package meant to be shared with my peers, I need a way to document the changes to that package over time, so my users have a transparent history incase any regression occurs due to the packages use.||Researched||Issue|
|When my pipelines have completed, I need an easy way to confirm my package was successfully published to the registry, so I can troubleshoot any possible issues early and have peace of mind that my code was successfully delivered to customers.||Researched||Issue|
|When I am troubleshooting a package related issue, I need an easy way to understand the history of changes by version of specific packages, so I can quickly identify and resolve the regression to improve the experience of our customers.||Researched||Issue|
|When my package or image is ready to be added to the registry, I need to be able to publish the package using the command line, so my changes can be delivered to production without any interruption in experience.||Researched||Issue|
|When I am troubleshooting a bug related to a package, I need be quickly connected with the pipeline, branch, and commit related to this version, so I can identify the problem area and create an informed action plan forward.||Researched||Issue|
|When I am working with packages related to a bug, I need an easy-to-access reference to what a specific package is dependent on, so I can identify a possible problem area and move forward towards resolving the degradation in experience.||Researched||Issue|
|When I am selecting which package to add to my code base, I need to know at a glance when this package was created or last updated, so the addition of the package is less likely to interrupt the experience and introduce regressions.||Researched||Issue|
|When I am troubleshooting a bug related to a package, I need to quickly find a list of any common issues or bugs, so I can make an informed decision on how to resolve the issue.||Researched||Issue|
|When I need to add a package to my codebase, I need to know the packages that my DevOps team have verified are good to use, so I can help in delivering a consistent experience across the code base and product.||Researched||Issue|
When my organization is exploring whether to move to new DevOps tool, I want to understand GitLab’s Package and Container Registries capabilities, so my organization can make an informed tooling decision.
|When my organization is considering using GitLab's Package Registry, I need to easily discover and understand what features exist, so I can help my organization determine if moving to GitLab’s registries is in the best interest of the company.||Researched||Issue|
|When I am exploring the viability of GitLab’s Package Management solution, I need to understand what would keep my organization from being able to use the tool, so I can help my organization make an informed decision.||Researched||Issue|
|When I am evaluating GitLab's Package Registry, I need an easy way to understand the relevant expected costs, so I can make an informed purchasing decision related to Package and Container Registries.||Researched||Issue|
|When I am considering different package managers for my organization to use, I need to understand how GitLab's product offering compares to what my team is currently using, so I can make an informed decision.||Researched||Issue|
|When I am first exploring different package managers, I need to know if GitLab can support all of my organization's package managers, so I know whether GitLab’s solution is a good fit for my organization.||Researched||Issue|
|When I am first exploring package manager solutions, I need to understand what the process and timeline of a migration, so I can know if/when I can stop paying for third party package management solutions.||Researched||Issue|
|When I am considering the usage of GitLab’s registries over a third-party alternative, I need to understand when I will be able to stop needing a 3rd party package manager, so I can make an informed cost versus reward analysis.||Researched||Issue|
When my organization decides to move forward with GitLab’s Package offering, I need to efficiently plan and migrate my organization’s packages and images to GitLab’s Registries, so I can bring these resources into the single secure DevOps tool without causing disruption to my team.
|When my team migrates to the GitLab registries, I need an easy way to set up or change my Ci/CD pipelines, so my packages or images are automatically created and stored in the correct registry.||Researched||Issue|
|When I am first using the GitLab Package and Docker Container Registries, I need easy access to help and documentation, so I can quickly get up to speed on the new tool and delivery code-packages efficiently.||Researched||Issue|
|When my organization is in the process of migration, I need to make the necessary authentication tokens and authorizations, so developers have the correct permissions to read/write to the appropriate registries.||Researched||Issue|
|When my team or organization needs to migrate to the GitLab Package/Container Registry, I need an easy easy way to publish packages from a 3rd party registry over to GitLab, so my organization can pull the required resources from GitLab's registry without experiencing any interruption.||Researched||Issue|
|When my team is migrating to the GitLab's Package/Container Registry, I need to understand how this migration will impact my development workflows and when I’ll need to know when to make that transition, so I can continue delivering feature improvements with limited interruption.||Researched||Issue|
|When my team or organization needs to migrate to the GitLab Package/Container Registry, I need an easy easy way to publish a package from my computer to the registry, so I can confirm I have correct privileges and the ability to use the registries.||Researched||Issue|
|When my company is in the process of Package and Image migration, I need to know when the migration is complete, so that I can cancel the other service(s) safely.||Researched||Issue|
|When my organization is in the process of migration, I need to understand the status of the migration and how long it is taking, so I can accurately report on progress, monitor for any possible issues, and understand the overall impacts to the organization.||Researched||Issue|
When my development ecosystem begins to mature, I need an overall view and understanding of my organization’s registry and package usage, so I can make effective development and architectural decisions.
|When I am reviewing the security and compliance of my codebase, I need an easy way to review the quality of my package dependencies, so I can minimize the risks of customers or fellow engineers experiencing a degraded experience.||Researched||Issue|
|When I need to make decisions that impact how my team utilizes a package manager, I need to understand which packages are being used and by which projects, so that I can ensure my team is using the correct versions of packages and not introducing risk into the pipeline.||Researched||Issue|
|When I am making decisions around my teams package-related architecture, I need to see my org's most commonly used packages or images, so I can better understand our platforms dependencies and make informed decisions.||Researched||Issue|
When my organization utilizes the GitLab Package and Container Registries, I need to understand how and when to engage with the package team, so I can actively contribute to making the registry experience better for myself and the broader open source community.
|I as a Community Member and open source enthusiast, I want to be able to actively contribute to GitLab’s Registry, so I can improve the experience and capabilities of the offering both for me and other GitLabbers. I need an easy way to discover open Package issues that are good candidates for community contribution. I also need to understand the best way to contribute and further engage with the package team to ensure a smooth MR and product experience.||Researched||Issue|
|When I am ready to contribute a larger scale change to the registry (like submitting a new package manager integration), I need to understand the best way to format and submit my contribution, so I can quickly and easily add my improvement to the experience.||Researched||Issue|
|When I get stuck or have a question when trying to contribute to the registry features, I need to understand the best way to interact/ask questions of the GitLab Package team, so I can move forward and contribute After I have submitted a community contribution to the Package team, I need to understand the outcome of my contribution and its impact on users, so I feel like my contribution is valuable and useful.||Researched||Issue|
When my organization is proxying/caching images and/or packages from external remotes, I need the Dependency Proxy to function seamlessly and reliably, so our developers have a consistently stable product development experience.
When my development ecosystem utilizes third-party package or image dependencies, I need to ensure these assets don't introduce security vulnerabilities and compliance violations to my codebase, so my development and product ecosystem can operate without interruption.
When I create different versions of artifacts I want those to be stored in a central and immutable place for easy access and distribution so that devices and users can consume the latest artifacts in release bundles.