Skip to end of metadata
Go to start of metadata

We would like to suggest 3 different approaches - these can be combined or performed independently from each other.

  • Divide and Conquer
  • Speed up on what we have
  • The 'Facebook' way

1. Divide and Conquer


Split release types
E.g. : Core (Kernel – Orchestration/instantiation?) releases VS Apps (OAM, CL, …) release
E.g. : Main Releases VS Service releases (like ODL)

-Main Releases can introduce new projects, new extended features
-Service Releases can introduce smaller features, smaller extension, can be done much faster


Operating System Model (piece by piece)


-Robust test suites and coverage to certify release
-Agree on “Quality Gates” that can certify a release / a service release
-Split Features into several categories i.e. Core, Service releases, Security releases etc.
-Because the cycles are shorter, and downstream projects more isolated from upstream, there are fewer Milestones with fewer requirements
-Imply to maintain more branches but for a short period (~4 weeks), clever selection of long lived branches (Long Term Support ?)
-Clear Configuration Management Strategy

2. Speed up on what we need


ONAP is already built on a daily basis
-All teams have implemented a daily release build, get everything from Master and build Staging artifacts including potentially shippable release containers
-Add a ‘weekly’ stable build candidate – Keep main release target but allow for features to be released prior the ‘official’ release date (e.g. alpha, beta builds)
-Dashboard Check on Monday and try to fix the open issues by Thursday EOD to release as an “experimental” release on Friday.


Features Centric


-Robust test suites and coverage to certify release
-Agree on “Quality Gates” that can certify a release / a service release – Decide core test suites, and priority focus on Ready-to-Go features
-Can be combined with a shorter cycle, could even allow to move content around releases (if the ONAP TSC accepts that scope can move)

3. The "Facebook" way

Create an immutable Release pipeline, that continuously build and push releases provided that :
-No breakage is detected during various test cycle
-No ‘Emergency stop’ is triggered by Dev or Test or ONAP TSC or anyone to stop the release
-Allow for feature branches to introduce more disruptive changes (maybe limit them per product to limit overhead)


Defects, small improvements


-Robust test suites and coverage to certify release
-Pull everything from Master, always move forward (no patch, no service release) – ideally this model can deliver multiple times a week
-Real Feature thinking, work on a smaller set of features - no ‘Big Name’ release anymore
-Additional LF infrastructure resources are available
-“Intelligence Release Robot” to be developed

  • No labels

1 Comment

  1. Catherine, this is an important activity; thank you for starting this.  During the Architecture meeting in Vancouver I presented some ideas in this area as described in slide 10 here: I propose two rules:

    1. All gerrit submissions must pass an CI/CD end-to-end test suite.
    2. The maximum size of a gerrit submission be constrained to some reasonable number (~5000 SLOC?).

    The intent is to ensure the master branch stays sane and that all parties work up-steam to avoid destabilizing ONAP with large changes dropped at the end of the release. The CD tests should be run against a long standing ONAP deployment via helm upgrades to emulate the use of ONAP in a operators production environment.

    These rules would potentially fit into all three of the above proposals.

    Cheers, Roger