Discuss the Kubernetes Agent UX vision and how it can be used by other product areas
Scope of discussion
We recently introduced the Kubernetes agent as the new Kubernetes management solution of GitLab. The focus so far has been on the implementation of the agent and making sure the core functionality is there. Now we are completing the technical side, we are starting to think about what are the user jobs that the agent can be used for, how the agent is going to be integrated in existing GitLab functionality, how it can be combined or enhance functionality that it seems to duplicate.
This issue is a place for us to discuss our vision for the agent and what user experience we envision for it - not just based on today's GitLab functionality but thinking in the context of GitLab in the future. Some of the questions that I have:
- Which other product areas could use and benefit from the Agent? (e.g. CI/CD)
- How does the Agent differs or enhances Progressive delivery and other CI/CD features?
- How does the Agent relate to Auto DevOps?
- Which existing user flows would the Agent creation/installation/utilisation be introduced to?
- How do we present the Agent as an entity? Is it a standalone entity or does it exist within other areas/functions? (eg. GitLab Kubernetes "plugins")
- How flexible should the Agent be? What is the out-of-the-box offering (with minimum configuration) and what Settings do we need to provide to users?
- How do we make the Agent:
- easy to understand and use
User experience goal
Ideally, we want to remove the complex manual configuration of todays experience, which is likely to discourage users from adopting the GitLab Kubernetes integration.
Our goals should be to:
- Minimise manual configuration and complexity.
- Maximise automation where users would like automation.
- Provide some level of configuration for the agent to enable flexibility for use cases we do not cover.
- Leverage the single application benefits. Enhance other GitLab features by integrating them with the agent or use the agent in other areas of the product that interact with the cloud infrastructure.
- Not confuse users by having to select between two GitLab features that do the same thing.