Uploaded image for project: 'OpenShift Builds'
  1. OpenShift Builds
  2. BUILD-654

Openshift Builds (Shipwright) GA : Product Management

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Major Major
    • builds-1.0
    • None
    • None
    • Openshift Builds (Shipwright) GA : Product Management
    • False
    • None
    • False
    • Not Selected
    • Done
    • SECFLOWOTL-24 - Openshift Builds (Shipwright) : GA v1.0
    • 0% To Do, 0% In Progress, 100% Done

      Epic Goal

      • A successful release of OpenShift Builds that has both technical and platform goals:
        • (technical) Enables the use of the Shipwright framework and supported build strategies to perform on-cluster builds.
        • (technical) Fully supports Buildpacks as a build strategy.
        • (platform) demonstrates Red Hat's commitment to an "end-to-end" outer loop development story in OpenShift.
        • (platform) provides the basis for an extensible and modular builds solution that offers value above and beyond the mere technical ability to run a build on-cluster (i.e. considerations for the Secure Software Supply Chain, performance benefits from utilizing shared cluster resources).

      Why is this important?

      • OpenShift's strength as a platform is partly dependent on the developer story. Improving the ease of building and deploying applications drives developers and workloads to OpenShift.
      • Builds support has been seen as a "weak link" in our outer loop story. We have comprehensive offerings in the form of Pipelines and GitOps, but Builds v1 (BuildConfigs, with support for docker image builds and Source-to-Image) is seen as inflexible and close-ended (though functional).

      Scenarios

      1. As a developer, I would like to be able to run more of my builds in the cloud, and specifically on the clusters which may be involved in deploying and running those workloads.
      2. As a developer, I would like to be able to use new build technologies that support multi- and hybrid cloud, and give me additional functionality while minimizing the effort involved in supporting this.
      3. As a platform engineer, I would like to see our CI/CD workflows run on our platform in a manner that leverages the strength of that platform, with powerful native integrations that improve the security, performance, and functionality of our CI/CD ecosystem.

      Acceptance Criteria (Mandatory)

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.

      Dependencies (internal and external)

      1. Shipwright upstream project

      Open questions::

      •  

      Done Checklist

      • Acceptance criteria are met
      • Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
      • User Journey automation is delivered
      • Support and SRE teams are provided with enough skills to support the feature in production environment

              rh-ee-ssadeghi Siamak Sadeghianfar
              spandura@redhat.com Shwetha Panduranga (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: