Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-8828

GitOps Operator available in Developer Sandbox

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • None
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • GITOPS-8827GitOps in Dev Sandbox
    • 100% To Do, 0% In Progress, 0% Done

      Feature Overview

      < High-Level description of the feature ie: Executive Summary >

      • The Developer Sandbox is a free trial environment. Although we do not have paying customers, we had 13.4k user sign-ups and influenced approximately $2 million in deals last quarter. Enabling GitOps on the Developer Sandbox will support Red Hat’s growth by helping teams experience the value of OpenShift and understand how GitOps integrates with other Red Hat products.
      • The Developer Sandbox provides a place for users to quickly and easily interact with GitOps Operator/Argo CD, which is a valuable part of the sales experience. In addition, having our team involved in maintaining GitOps on a production cluster enables easier testing and faster iteration when issues arise.

      [This question assists the Scrum team in prioritizing and organizing the outcomes. E.g. Customer demands, Strategic gaps, etc.]

      Goals

      < Who benefits from this feature, and how? What is the difference between today’s current state and a world with this feature? >

      Securely onboard the OpenShift GitOps Operator in the Developer Sandbox.
      Users can rapidly provision and enable OpenShift GitOps within their DevSandbox environment, allowing them to evaluate GitOps workflows in an isolated namespace without exposing cluster resources or data to other users.

      Requirements

      Requirements Notes IS MVP
      Define the deployment model of GitOps Operator on Developer Sandbox   Y
      Pass DevSandbox Performance Test   Y
      Easy-to-use User Experience   N

      Use Cases

      < What are we making, for who, and why/what problem are we solving?>

      Out of scope

      <Defines what is not included in this story>

      Dependencies

      < Link or at least explain any known dependencies. >

      Background, and strategic fit

      < What does the person writing code, testing, documenting need to know? >

      Assumptions

      < Are there assumptions being made regarding prerequisites and dependencies?>
      < Are there assumptions about hardware, software or people resources?>

      Customer Considerations

      < Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

      Documentation/QE Considerations

      < What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >
      < Does this feature have a doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>
      < Are there assumptions being made regarding prerequisites and dependencies?>
      < Are there assumptions about hardware, software or people resources?>

      Impact

      < If the feature is ordered with other work, state the impact of this feature on the other work>

      Related Architecture/Technical Documents

      <links>

      Definition of Ready

      • The objectives of the feature are clearly defined and aligned with the business strategy.
      • All feature requirements have been clearly defined by Product Owners.
      • The feature has been broken down into epics.
      • The feature has been stack ranked.
      • Definition of the business outcome is in the Outcome Jira (which must have a parent Jira).

              Unassigned Unassigned
              wtam_at_redhat William Tam
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: