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

Revise release processes for SDP repositories

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

Details

    • Enabler
    • Should have
    • PI20
    • COM SDP SW
    • None
    • True
    • Data Processing
    • Hide

      Making SDP releases takes a lot of effort due to the high number of interdependent artefacts that need to be created. This means that we are at danger of making releases that have internally inconsistent dependencies, which has already caused problems previously. The goal here is to make it easier (ideally automated) to integrate components and create consistent releases.

      Show
      Making SDP releases takes a lot of effort due to the high number of interdependent artefacts that need to be created. This means that we are at danger of making releases that have internally inconsistent dependencies, which has already caused problems previously. The goal here is to make it easier (ideally automated) to integrate components and create consistent releases.
    • Hide
      • release processes for SDP components that will allow us to quickly make collective patch releases of many SDP components to refresh shared dependencies (e.g. configuration library or an external dependency).
        • Ideally covering Helm, OCI image and Python package dependencies
      • Adjust CI processes to ensure that such releases are safe (e.g. automatically test with updated dependencies on a reasonable schedule).
      Show
      release processes for SDP components that will allow us to quickly make collective patch releases of many SDP components to refresh shared dependencies (e.g. configuration library or an external dependency). Ideally covering Helm, OCI image and Python package dependencies Adjust CI processes to ensure that such releases are safe (e.g. automatically test with updated dependencies on a reasonable schedule).
    • 2
    • 2
    • 5.5
    • Team_ORCA
    • Sprint 5
    • Hide

      Demo planned for PI21

      AC1: 

      We achieved the following:

      • Migrated and renamed the skairt repository to ska-rt: https://gitlab.com/ska-telescope/ska-rt 
      • Initial investigation and plan made for the work at the beginning of the PI:
      • Updated ska-rt to:
        • the CLI uses the `–mode` argument to determine what information to use from the skart.toml file for dependency updates. At the moment, this is used to distinguish between release and development version updates: MR4
        • Allow passing in custom configuration to the CLI (overwrites using skart.toml): MR8
        • Various updates and bug-fixes, including, e.g. in the way ska-rt identifies patterns in CI jobs to find release versions: MR1
      • Added three new make targets to ska-cicd-makefile. These are located in the dependencies.mk file. We also added relevant tests: MR227, MR228. These are:
        • deps-update: update dependencies with skart (development version mode) and poetry lock
        • deps-update-release: update dependences with skart in release mode and with poetry lock
        • deps-patch-release: updates dependencies -> bumps patch version -> pushes tag (and waits for tag pipeline to finish) -> pushes changes to main
      • Added the skart.toml file to every SDP repository listed in ORC-1822 description.

      Currently finishing off:

      • Recursive behaviour of ska-rt, which allows updating dependencies automatically for a whole dependency tree: MR7
      • This should be the final piece of the puzzle to get the automation working.

      We will need to address in PI21:

      • Need to update documentation in the SDP Integration repository to describe this release process: ORC-1839
      • Need to make a first release of ska-rt with the new functionality: ORC-1840

      AC2:

      • Not achieved. We have not adjusted any of the CI pipelines to use the new release process. This will need to be addressed in PI21.
      Show
      Demo planned for PI21 AC1:   We achieved the following: Migrated and renamed the skairt repository to ska-rt: https://gitlab.com/ska-telescope/ska-rt   Initial investigation and plan made for the work at the beginning of the PI: https://confluence.skatelescope.org/display/SE/Investigation+into+automating+the+release+process https://confluence.skatelescope.org/display/SE/Proposed+plan+of+process+execution Updated ska-rt to: the CLI uses the `–mode` argument to determine what information to use from the skart.toml file for dependency updates. At the moment, this is used to distinguish between release and development version updates: MR4 Allow passing in custom configuration to the CLI (overwrites using skart.toml): MR8 Various updates and bug-fixes, including, e.g. in the way ska-rt identifies patterns in CI jobs to find release versions: MR1 Added three new make targets to ska-cicd-makefile. These are located in the dependencies.mk file. We also added relevant tests: MR227 , MR228 . These are: deps-update: update dependencies with skart (development version mode) and poetry lock deps-update-release: update dependences with skart in release mode and with poetry lock deps-patch-release: updates dependencies -> bumps patch version -> pushes tag (and waits for tag pipeline to finish) -> pushes changes to main Added the skart.toml file to every SDP repository listed in ORC-1822 description. Currently finishing off: Recursive behaviour of ska-rt, which allows updating dependencies automatically for a whole dependency tree: MR7 This should be the final piece of the puzzle to get the automation working. We will need to address in PI21: Need to update documentation in the SDP Integration repository to describe this release process: ORC-1839 Need to make a first release of ska-rt with the new functionality: ORC-1840 AC2: Not achieved. We have not adjusted any of the CI pipelines to use the new release process. This will need to be addressed in PI21.
    • PI22 - UNCOVERED

    • Com-G2

    Description

      Release processes could roughly as follows - for every involved repository (in dependency order!) do:

      1. update to newest released (!!) dependencies (or hold back manually), e.g. using `poetry update`
      2. commit the new dependencies (i.e. poetry.lock)
      3. create a tag for the registry
      4. push and have CI build the actual registry package
      5. ... continue for next layer

      To ensure that this does not generate new surprises, CI tests should ideally also be adjusted to run `poetry update` (to get current external dependency releases) and ideally `skairt update` (to get "bleeding edge" packages - likely needs work!). If nightlies were staggered in dependency order with a ~1 hour gap this would mean we build everything every night from the bottom up, giving us strong assurances that

      1. Problems are going to get spotted as early as possible
      2. The above release process has a high likelihood to succeed

      See also considerations from SP-1372 (now discarded)

       

      Attachments

        Issue Links

          Structure

            Activity

              People

                p.wortmann Wortmann, Peter
                m.ashdown Ashdown, Mark
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 2.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete1730.0
                  Total1730.0

                  Dates

                    Created:
                    Updated:

                    Structure Helper Panel