Page History

• The goal of the Kick-Off review is to declare intention to participate in an ONAP Release.
• The proposed Project aligns with the architecture, team is in place, draft project plan is well-formed in wiki. 
• Once approved, the planning process opens. 
• Once approved, the team can start refining architecture, coding, testing, and documenting.
• Release Kick-Off review takes place for each next releases.
• TSC formally provides its formal disposition.

• Establish Release Kick-Off in wiki by filling out Release Kick-Off Template.
• Define impacts on other projects.
• Include estimated time and resource plans.
• Post Proposal in "Proposing a Project" wiki page.

Once the Release Kick-Off passed, the following activities are performed:

• Release Use Case are iteratively worked on, submitted to TSC and proposed to GB.
• Development of feature code.
• Development of feature test case.
• Continuous Integration Continuous Delivery process is created (All repositories are created).
• The Integration Team defines an End to End Release Test Case.

• The goal of the Release Planning review is to ensure the plan is complete, sufficient, and aligned with release milestones.
• The team has a high level of confidence they will make the Release Sign-Off date.
• Issues brought to TSC.
• At Release Planning, the following activities have been achieved:
  • Release Use Case(s) is (are) already approved by GB.
  • Release scope is defined and agreed on (Epics defined in Jira, Stories for next 2 Iterations groomed).
  • All people resources are identified, documented and committed.
  • All Release Components Name and structure is defined and documented.
  • Project Plan supporting the Release is carefully documented. 
  • The functional Architecture for the project is defined and carefully documented (block diagram, sequence diagram,...)
  • Dependencies between projects are identified.
  • End 2 End Continuous Integration Use Case (CSIT) Release Test Case is defined (Integration Team).
  • The vendors equipment list is defined (Integration Team).
  • The CI/CD Tool Chain is in place (Defined by Project Team and setup by LF).
  • Documentation plan is available (Release Notes, Installation Guide, Configuration Guide, User and Admin Guide,...).
  • Training Materials plan is available.
  • Release scope is defined and agreed on (Epics defined in Jira, Stories for next 2 Iterations groomed)
  • All people resources are identified, documented and committed.
  • All Release Components Name and structure is defined and documented.
  • Project Plan supporting the Release is carefully documented. 
  • The Installation strategy is defined.

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 Release Lifecycle Deliverables for Planning Milestones template
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

• The goal of the Functionality Freeze is to mark the end of

• adding functionality in the Release.
• After Functionality Freeze, no new visible functionality is to be added to the current ONAP release.

• The API definition development activities is over and a stable document describing the API is documented and available to the community.
• At Functionality Freeze, the following activities have been achieved:
  • All committed functionalities have been coded.
  • CSIT Test Case are defined (Project Team).
  • All code have automated unit test (Project Team).
  • 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.

All defects must be entered into Jira.

• The goal of the API Freeze is to ensure API and Data Model are Frozen.
• At API Freeze, API stubs must be in implemented.
• All provisional APIs are at least functional (at a beta-quality level) if not yet fully testedArchitecture 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.
• Any Changes to the API must be brought to the knowledge of the TSC for review and approval. 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.
• 50% of CSIT Test case complete(Project Team).
• Issues brought to TSC or Architecture Committee (ARC).

• Coordinator.

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.

• The goal of the Integration review is to ensure proper alignment on integration testing for all projects participating in an ONAP release.
• At that point, a fully-built, complete version of the current ONAP 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.
• At RC0, the following activities have been achieved:
  • Automated End to End Deployment must be complete
• At RC1, the following activities have been achieved:
  
  • The Training Materials are available for review
• At RC2, the following activities have been achieved:
  • ...

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.