Uploaded image for project: 'SAFe Program'
  1. SAFe Program
  2. SP-130

Define and describe CI common architecture

Change Owns to Parent OfsSet start and due date...
    XporterXMLWordPrintable

Details

    • Enabler
    • Not Assigned
    • PI3
    • None
    • Hide

      A common CI infrastructure is often emerging as one of the main derived from the consortia setup of the design consortia.

      Maybe this is not a top priority in terms of documentation for system CDR, but it is certainly important content that should be an integral and fundamental part of system level plans and design.

       

      Show
      A common CI infrastructure is often emerging as one of the main derived from the consortia setup of the design consortia. Maybe this is not a top priority in terms of documentation for system CDR, but it is certainly important content that should be an integral and fundamental part of system level plans and design.  
    • Hide

      Proposal is to extend SDP Software Management C&C (or develop something equivalent, personally I would prefer keeping the SEI style) such that it can be used as a shared CI architecture description for different SKA software sub-systems.

      This should:

      • Show how the CI system would interact with relevant SKA software systems. Likely all via artefact repository.
      • Decompose CI infrastructure a bit, clarifying that we need build servers (possibly multiple flavours for access to specialised hardware), and possibly dedicated license servers
      • Show more explicitly that we want to make certain build artefacts (such as test reports and built documentation) available to developers.
      • Might want to add deployment diagrams, showing how the different components might be spread across different SKA sites and the cloud (this should likely remain a variability, i.e. illustrative for the moment).
      Show
      Proposal is to extend SDP Software Management C&C (or develop something equivalent, personally I would prefer keeping the SEI style) such that it can be used as a shared CI architecture description for different SKA software sub-systems. This should: Show how the CI system would interact with relevant SKA software systems. Likely all via artefact repository. Decompose CI infrastructure a bit, clarifying that we need build servers (possibly multiple flavours for access to specialised hardware), and possibly dedicated license servers Show more explicitly that we want to make certain build artefacts (such as test reports and built documentation) available to developers. Might want to add deployment diagrams, showing how the different components might be spread across different SKA sites and the cloud (this should likely remain a variability, i.e. illustrative for the moment).
    • 8
    • 8
    • 1
    • Team_SYSTEM
    • Sprint 5
    • Hide

      https://docs.google.com/document/d/17vTU4IGJpUc_QEhJzxOgC_R4GHYHJ3DAmEagJ4sZTGQ/

      Relative to the acceptance criteria - somewhat partial points on showing interaction with other SKA elements (left mostly open, but that's likely enough), but CI decomposition and user interfaces have been fleshed to a pretty high standard. Haven't really looked at deployment, but this might not be critical right now. An extra data entity view was added.

      Show
      https://docs.google.com/document/d/17vTU4IGJpUc_QEhJzxOgC_R4GHYHJ3DAmEagJ4sZTGQ/ Relative to the acceptance criteria - somewhat partial points on showing interaction with other SKA elements (left mostly open, but that's likely enough), but CI decomposition and user interfaces have been fleshed to a pretty high standard. Haven't really looked at deployment, but this might not be critical right now. An extra data entity view was added.
    • 3.6
    • PI24 - UNCOVERED

    • Team_SYSTEM

    Description

      Now that we have a basic running infrastructure in place to support preliminary development activities we need to take a step back and think about the larger picture.

      An overall architecture for the SKA CI and CD environment needs to be consolidated, starting from existing documents from design consortia.

      The architecture presented will need to take into account possible adoption of different platforms and be generic enough to be adaptable to cloud or on premise deployment, supporting the different range of products and technological solutions encompassed by the project.

      The output should include a description of how someone can integrate specialist hardware test platform into the SKA CI Common infrastructure. 

      Attachments

        Issue Links

          Structure

            Activity

              People

                p.wortmann Wortmann, Peter
                m.bartolini Bartolini, Marco
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 8.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete818.0
                  Total818.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel