Container Registry: User Research July 2019
Problem to solve
In May 2016 GitLab launched the MVC of the Container Registry. The container registry leverages the open-source Docker Registry to allow users to build, push and share Docker images and tags within their GitLab project. It also integrates with GitLab's CI/CD products to allow users to manage their images programmatically while testing and building their code.
Today, the feature is widely adopted by GitLab users. With increased adoption, we have seen an increase in requests to improve and enhance the functionality of the container registry. Our most commonly requested features are:
- Improved management features (tag pruning, garbage collection, retention and expiration policies)
- Secure authentication methods and permissions models (deploy tokens, OAuth, specific user roles)
- Improved usability and user experience (sorting, search, filtering, group level view, ability to transfer projects)
In order to deliver many of the above features, we must make a significant investment in the container registry. https://gitlab.com/gitlab-org/gitlab-ce/issues/62885# discusses the technical implications of this investment. In addition to understanding the technical implications, we need to ensure that our product roadmap, designs and features are in-line with our users' needs and values.
In order to capture that alignment, the Package team would like to conduct user research to better understand our users' needs, validate our category strategy and ensure we prioritize, design and build features based on the needs of our users.
Business Decision(s)
- Utilize user research data to align on the maturity path and investment in the GitLab Container Registry.
Hypothesis
- Users need improved management features for the container registry that are highly customizable and work seamlessly with GitLab's CI/CD features.
Goals
- Understand and document the requirements for helping our users to better manage the Container Registry.
Objectives
- Understand how users are currently using Gitlab and/or other tools for Container Management.
- Understand the Container Management workflow.
- Identify the barriers to effective management of the Container Registry.
- Understand how various barriers affect users' ability to effectively manage the Container Registry.
- Identify additional Container Management features users would benefit from having in Gitlab.
Scope
- Interview 5 internal users to understand how GitLab engineers are building, pushing and deleting images/tags from the Container Registry.
- Interview 10 external users to understand how our customers are building, pushing and deleting images/tags from the Container Registry.
- Interview 5 users that are not currently using GitLab for their container management and understand how they are deleting images/tags.
Diversity
Diversity and inclusion are fundamental to the success of GitLab. As such, we will seek to recruit a diverse, inclusive set of interviewees.
Questions we want to know the answers to:
- How often do users build and push new images?
- How collaborative, if at all, is the process of building and pushing new images?
- How are users interacting with the Container Registry today? API, UI, CI/CD, CLI?
- Who is responsible for managing storage and how do they currently do it?
- Which storage configuration is most common?
- What are the risks of enacting retention and expiration policies for managing storage?
- What do users expect to be able to do from the GitLab user interface? (stretch goal)
Interview
Introduction
Hi ,
How are you doing today?
Where in the world are you calling me from?
I’m , I’m a at GitLab and my colleague, is also on the call. I’m going to be asking you a few questions in relation to the Container Registry.
I like to keep these sessions pretty informal. I’m just trying to learn from you today. I’ll ask a lot of questions, but I’m not testing you. There are no right or wrong answers. If you’re not sure of something or perhaps you don’t feel comfortable sharing something with me, then don’t worry about it, just tell me and we can move on.
Before we begin, could I just confirm that you’re still okay with me recording our conversation and sharing it on GitLab?
Super! Do you have any questions before we get started?
PRESS RECORD
Background info
- What’s your current role?
- How long have you been in that role?
- What would you say are your top 3 tasks?
- What kind of work does your company do?
- What do you use Gitlab for?
Software Developer Track
- Walk me through how you build a docker image
- How is it built? (API, CLI, CI/CD)
- Why do you choose that method?
- What issues, if any do you have with that process?
- How is it built? (API, CLI, CI/CD)
- Now that it's built, can you show me how your or your team use this image?
- Are you currently using tags, if so how?
- How do you and/or your team know that this is the approved image?
- How many people rely on this image?
- Anything else about the image we need to know?
- How do you determine when to create a new image vs. edit this one?
- Show me how you would edit an existing image.
- What's the typical time an image is in use?
- How will you know when it's not useful?
- Who is responsible for making that decision?
- Anything else about this process we need should know?
- Walk me through how you delete an image.
- How about: How much storage does your project currently utilize? How do you use that information?
- In which situations is it important for you to know the amount of storage?
- Tell me about the last time you had problems deleting images. What went wrong? How did that affect things?
- How would you do this programmatically?
- What, if any other services do you use for container management? What do you like about them? What do you not like? How do they fit into your processes compared to Gitlab?
System Administrator Track
- Walk me through how you build a docker image
- How is it built? (API, CLI, CI/CD)
- Why do you choose that method?**
- How is it built? (API, CLI, CI/CD)
- How do you currently manage old, retired images?
- How many projects/groups do you do this for? How many developers?
- How do you know which images are ready for deletion?
- Tell me about the last time you removed an image. What went well? what went wrong? And then you can ask:
- Have you ever removed the wrong image(s)? if so, what happened? How did that affect things?
- How do you validate the process worked?
- How much clean-up do you expected developers to do? Why? Do you they verify this?
- When do you normally do this?
- How would you solve this problem programmatically?
- What specific naming conventions does your team follow? Why?
- What best practices does your organization follow for retiring old images?
- Who should be able to determine the rules around this?
- What security concerns do you have around container management
- What other services solve this type of problem well for you? What is it about them that have them solving the problem(s) well for you?
- What visibility do you need that you currently don't have?
- What would having that visibility enable you to do?
- How would others use that new visibility?
Wrap Up
Thank you very much for taking the time to speak with me. We’re constantly trying to improve GitLab and your input today has been really valuable. We’ll be sharing your thoughts with the Product team here at GitLab.