Page tree
Skip to end of metadata
Go to start of metadata

The activities of the OPEN-O (Open Orchestration) community are articulated around Projects and Releases.

The Release Lifecycle should be considered as a sub process of the overarching Project Lifecycle.

The Project Lifecycle should be seen as a long term endeavor (1-2 years) whereas the Release Lifecycle has a short term goal (next 5-6 months).

All projects approved for a release have its deliverables made available in sync at the end of the release. It results in a single release at the end of the development cycle.

The OPEN-O current release plan is available here.

Release Lifecycle Overview

OPEN-O releases are organized through review milestones that take place separately for every projects.

Release Review

Release Kick-Off

ReviewsMilestonesDescriptionActivities
Kick-OffM0
  • The goal of the Kick-Off review is to declare intention to participate in an OPEN-O Release.
  • The proposed Project aligns with the architecture, team is in place, draft plan is well-formed in wiki. 
  • Once approved, the planning process opens. 
  • The first release Kick-Off is the same review as the Project Proposal Review (same meeting, same deliverable).
  • Release Kick-Off review takes place for each next releases.
  • TSC formally provides its formal disposition.
To reach Release Kick-Off review, the team must:
  • Establish Release Kick-Off in wiki by filling out Release Kick-Off Template.
  • Define impacts on other projects.
  • Include estimated time and resource plans.

Release Planning

ReviewsMilestonesDescriptionActivities
PlanningM1
  • The goal of the Release Planning review is to ensure the plan is complete, sufficient, and aligned with release milestones.
  • Use cases and release scope is defined and agreed on.
  • The team has a high level of confidence they will make the Release Sign-Off date.
  • All resources are identified and committed.
  • Plan is carefully documented. 
  • Issues brought to TSC.

To pass Release Planning review, the PTL must:

  1. Fill out in project space release planning by filling out Release Planning Template
  2. Fill out in project space the Deliverables for Planning Milestonetemplate
  3. Inform the TSC Chair and the Release Manager prior to the milestone on the availability of the deliverable
  4. Have a concrete project time plan in place that accommodates dependencies and resource availability

 

Once the Release Planning review passed, the following activities are performed:

  • Development of feature code. 
  • Development of feature test case.
  • Continuous Integration process is in place.

Release Functionality Freeze

ReviewsMilestonesDescriptionActivities
Functionality FreezeM2
  • The goal of the Functionality Freeze is to mark the end of the API definition development activities. At Functionality Freeze, API stubs must be in implemented.
  • After Functionality Freeze, no new visible functionality is to be added to the current OPEN-O release.
  • After Functionality Freeze, all API definition changes must be submitted to TSC for review and approval.
  • All provisional APIs are at least functional (at a beta-quality level) if not yet fully tested.
  • At Functionality Freeze, the following activities have been achieved:
    • All committed functionalities have been coded.
    • All code have automated unit test.
    • The team is using the complete Linux Foundation environment (build, Jenkins, Gerrit, FOSS, Automated Unit Test, Nexus).
    • A defined and documented final list of externally consumable APIs is available.

To Pass Functionality Freeze, the PTL must:

  1. Fill out in project space the Deliverables for Functionality Freeze Milestone template
  2. Inform the TSC Chair and the Release Manager prior to the milestone on the availability of the deliverable

After Functionality Freeze is passed, the team focus on:

  • Feature Test:
    • Define Feature Test plan.
    • Define Acceptance criteria.
    • Automate and execute the Feature test.
    • Prioritize defects and address at least all critical and blocking defects.
  • Documentation:
    • Identified the kinds of documentation to be provided (Release Notes, Installation Guide, Configuration Guide, User and Admin Guide,...)
    • Create documentation files with outlines
    • Commit those files in an appropriate location

All defects must be entered into Jira.
Team coordinates with central Integration Team on testing plan.

Release Architecture

ReviewsMilestonesDescriptionActivities
ArchitectureM3
  • The goal of the Architecture review is to ensure architecture alignment with all projects participating to an OPEN-O release.
  • At Architecture review, API and Data Model are Frozen.
  • Architecture should be carefully documented and stable (API, block diagram, flow diagram,... defined).
  • All externally accessible APIs & data models may not be modified. An API exception process will allow for critical changes to APIs after API Freeze with the consent of the consuming projects. APIs include, but are not limited to, all Java classes/interfaces declared public , all YANG models, all TOSCA profiles, all config file YANG schemas, and all REST/RESTCONF calls including the full URL with options.
  • Issues brought to TSC or Architecture Committee (ARC).

Note: Projects in Incubation State would have a lower threshold than projects in Mature/Core State.
Project in Core State would have a high threshold.

Prior to Architecture review, Project teams must also review APIs with the Architecture Committee (ARC).


To pass Architecture review, the PTL must:

  1. Fill out in project space the Deliverables for Architecture Milestone template
  2. Inform the TSC Chair and the Release Manager prior to the milestone on the availability of the deliverable

It is important to understand that activities started at Functionality Freeze are still ongoing until Code Freeze milestone.

Release Code Freeze

ReviewsMilestonesDescriptionActivities
Code FreezeM4
  • The goal of the Code Freeze is to mark the end of the Features testing and the resolution of all impacting defects (at least all Critical and Blocking defects)
  • After Code Freeze, no new features/functionality are to be allowed into the current release. Only defects identified in the Jira system are allowed. The exceptions to this include new tests, and documentation
  • Distribution packaging must be complete
  • Defects found after Code Freeze are still defects and they may be created and worked on. This includes packaging defects found as well

To pass Code Freeze, the PTL must:

  1. Fill out in their Project Space the Deliverables for Architecture Milestone template
  2. Inform the TSC Chair and the Release Manager that the milestone has been achieved (or not)
  3. Inform the TSC Chair and the Release Manager prior to the milestone on the availability of the deliverable

At that point the Documentation is complete: Only editing and enhancing should take place after this point.

After Code Freeze is passed, the team focus on:

  • Integration Testing
    • Coordinate with central Integration Team to ensure end to end Integration testing is understood, complete and prepare a plan for Integration Testing review
    • Refine Integration Test plan
    • Refine Acceptance criteria
    • Start automating and executing end to end Integration testing

Release Integration Release Candidate

ReviewsMilestonesDescriptionActivities
IntegrationRC0
  • The goal of the Integration review is to ensure proper alignment on integration testing for all projects participating in an OPEN-O release.
  • At that point, a fully-built, complete version of the current OPEN-O release is available. This includes all code, documentation, and packaging that make up the final user-deliverable set of artifacts.
  • After Integration Review (RC0), new RCs will be continually built, e.g., once per day, to enable rapid testing and fixing of defects. 
  • Integration plan is defined and covers correct API calls and data models between projects, alignment with use case and test framework.
  • Integration Plan should be carefully documented.
  • Issue brought to TSC.
To pass Integration review, the PTL must:
  1. Fill out in their Project Space the Deliverables for RCx Milestone template
  2. Inform the TSC Chair and the Release Manager prior to the milestone on the availability of the deliverable


After Integration review is passed, the team focus on:

  • Executing the Integration Plan.
  • Prioritizing new defects and address them. In case there are blocking defects preventing the team to execute according to the plan, the defect must be fixed and a new full build made available.
  • Reviewing and polishing documentation.
  • Prepare activities to reach Release Sign-Off.
  • There is no need to create specific materials for RC1, RCx.

Release Sign-Off

ReviewsMilestonesDescriptionActivities
Sign-Off 
  • The goal of the Release Sign-Off review is to ensure that:
    • The project has successfully passed all previous reviews
    • All committed deliverables are available and reach expected quality criteria
    • All testing activities are complete and successful
    • All documentation activities are complete and available
    • All blocking issues have been successfully addressed (otherwise there is no reason to hold the review).
  • These above statements are the condition for the release to be included in the OPEN-O target release.
  • TSC formally provides its disposition.
To pass Release Sign-Off review, the team must:
  1. Fill out in their Project Space the Deliverables for Release Sign-Off Milestone template
  2. Inform the TSC Chair and the Release Manager prior to the milestone on the availability of the deliverable

 

Release Sub-Components

Some project teams may need to embed within their releases a set of Sub-Components. Sub-Components can be seen as a distinct piece of code that can be easily upgraded independently from the release deliverable. These Sub-Components must be clearly identified at Release Planning.

Release Components and Sub-Components are defined for all OPEN-O projects in a central place.

Some tailoring may take place to facilitate operation as we do not want to overload TSC voting members for relatively small sub-project updates.

Release Reviews

To avoid too much of formal review, TSC will provide its formal approval for project Kick-Off and Sign-Off only. However, all reviews must be carefully documented in project wiki with "Preparing Milestone" and "Passing Milestones" templates.

The same principles applies for Release Reviews as for Project Reviews.
Refers to Metrics Overview for details.

Release Tailoring

Depending on the release scope and project state, the Release Kick-Off and Release Planning Reviews may take place at the same time.

Architecture Review may be skipped for testing or documentation project.

Sub-Component Patch: when it is required to deliver a patch to address a critical issue, a simple email notification to TSC and Release Manager is required.

Release Naming

The naming convention for each OPEN-O release follows the sun and planets of the solar system.

  1. Sun
  2. Mercury
  3. Venus
  4. Earth
  5. Mars
  6. Jupiter
  7. Saturn
  8. Uranus
  9. Neptune
  10. Pluto

Mnemonic Advice: My Very Educated Mother Just Served Us Nine Pizzas

OPEN-O Release

Release Calendar