Versions Compared

Old Version 22

changes.mady.by.user Marek Chwal

Saved on

compared with

New Version 23

changes.mady.by.user Marek Chwal

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Info

Note: please refer to previous discussion Business-level Requirements for TF Release Process

Initially, due to the absence of release definition and process, community release needs to be aligned with some Contrail commercial release. Once the Community establishes its own independent release definition and process, all commercial releases including contrail can be aligned to community release.

This alignment is necessary to allow migration between the community and commercial release. As long as this alignment is maintained, Commercial release can follow any other release frequencies.

Aligning with Contrail commercial release to begin with we have following options:

  1. We do a release out of old branch R1911 now to bridge the gap from the last community release of r5.1 and look forward to do next release in June, 2020 aligning with Contrail release of June - 
  2. We skip the releases between r5.1 and R2002, and look forward to do next release in March, 2020 aligning with Contrail release of March

The purpose of the release process

...

Release Process

The unit piece of functionality/work which can be included in the release is represented by the Epic ticket in Jira. The release process consists of several Milestones in the pipeline of epics with clearly defined acceptance criteria. One can treat these acceptance criteria as a checklist that has to be followed to say that particular epic achieved this  Milestone.  Overall flow is outlined as follows:

  1. Invitation of proposals for features, enhancement requests - approved till M0
  2. Blueprints/Design/Architectural approval cut-off date (4 months before release date)
  3. Code delivery cut-off date (2 months before release date) - till M4
  4. Branch cut-off date (1 month before release date)
  5. Stabilize the branch and build daily builds for 1 month
  6. Release the stable build as Community Release
  7. Build weekly/bi-weekly if any change committed to the branch


Milestones goal and acceptance criteria

MilestoneGoal of the Milestone Description of the Milestone - acceptance criteria
M0Declaration of participation in the release, initial scope of the release
  • Blueprint proposal represented as a Jira EPIC ticket
  • Feature lead assigned to Jira Epic ticket - declaration of participation in the simultaneous release
  • The initial version of Increment Blueprint stored on Github/tf-spec/Release folder,
  • The blueprint presented, discussed, and approved by related committers 
  • Release Scope Overview updated accordingly
  • The initial version of the Release Plan for the project presented
  • Dependencies between projects/components/areas identified
M1

Identification of dependencies between modules and new functionalities,
release plan for new functionality 

  • All dependencies between existing functionality and requested change/feature discussed and agreed by PTL and related approvers (based on Modules/Committers)
  • Jira Epic ticket broke down into stories in related Jira project (backlog, plan) - presented and discussed on TWS meeting
  • The final version of Blueprints, Release Scope and Release Plans for participating projects discussed and approved by approvers
M2

Feature/Functionality

technical design freeze

  • Technical design fully provided, agreed (documentation on the Confluence/Github/tf-spec available)
  • Jira Epic ticket updated with a link to technical design
  • Documentation started
  • Feature tests started
  • Feature/Functionality Freeze - Technical Design approved by relevant approvers (Modules/Committers)
M3

API freeze (beta available)

  • External API available for beta-tests
  • Jira Epic ticket updated with information about API availability (documentation link - tf repo)
  • Documentation in progress
  • Tests in progress
  • API Freeze confirmed by Feature Lead (comment on Jira Epic ticket with repo/commit ID link)
M4

Code freeze - only bug fixing allowed

  • all functionality and APIs available for testing
  • Jira Epic ticket updated with information about final API documentation, executed UI tests documentation
  • Documentation provided - confirmed by Documentation project PTL
  • Code freeze confirmed by Feature Lead (comment on Jira Epic ticket) - only bug fixing allowed
RC0

Release candidates freeze 

- branch stabilization 

  • Release candidates agreed, approved, tested
  • System tests conducted, quality confirmed by CI/CD PTL
  • Final documentation provided, reviewed, approved by Documentation PTL
  • Marketing information provided to Marketing Advisory Council
  • release branch cut off - branch stabilization from now on
  • Release Candidates freeze, confirmed by PTL and TSC
DeploymentRelease deployment

official deployment executed



Release Cadence, Life Time & Support

The initial release cadence is planned for every 6 months. The initial release process is waterfall-based, but the Community intends to move into a more agile approach in the future.

The Community intends to actively support any release for up to 9 months, where any bug fixes will be committed and made available.

...