User Tools

Site Tools


releases:releaseplanning

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
releases:releaseplanning [2016/03/21 16:16]
Frank Brockners
releases:releaseplanning [2016/03/22 20:34] (current)
Frank Brockners [Release Structure for Colorado (Proposal)]
Line 3: Line 3:
 ===== Release Structure for Colorado (Proposal) ===== ===== Release Structure for Colorado (Proposal) =====
  
-The Colorado release will be framed around scenarios. Within OPNFV a scenario is a "​deployment of a set of components and their configuration"​. Colorado will include all scenarios which are available and ready by the Colorado time frame.+The Colorado release will be framed around scenarios. Colorado will include all scenarios which are available and ready by the Colorado time frame.
  
-{{:​releases:​opnfv_release_and_scenario_releases.pdf|Overview presentation of scenario ​releases.}}+{{:​releases:​opnfv_release_and_scenario_releases.pdf|Overview presentation of scenario ​editions.}} (presented at OPNFV Hackfest, Santa Clara, March 14-15, 2016).
  
  
-==== Scenario-based ​releases: Background and Objectives ====+==== Scenario-based ​release coordination: Background and Objectives ==== 
 + 
 +  * Scenario definition:​ 
 +    * Within OPNFV a scenario is a "​deployment of a set of components and their configuration"​. 
 +  * Scenario ownership:​ 
 +    * Scenarios have a clearly identified owner and scenario leader who serves as the main point of contact. The scenario owner would typically be a project or a set of projects that all contribute features to the assembly of components that constitutes the scenario. A scenario could also be owned by a single project (that might even be the sole purpose of a project).
  
   * OPNFV test components and features at system level   * OPNFV test components and features at system level
Line 17: Line 22:
   * Accommodate for the fact that not all scenarios are created equal (some are complex, some are simple)   * Accommodate for the fact that not all scenarios are created equal (some are complex, some are simple)
  
-==== Scenario-based ​releases: Approach ====+==== Scenario-based ​release coordination: Approach ====
  
   * Per scenario schedules   * Per scenario schedules
     * Not all scenarios are of the same complexity: Allow for per scenario schedules; allow scenarios to define their own schedule     * Not all scenarios are of the same complexity: Allow for per scenario schedules; allow scenarios to define their own schedule
-  * Scenario ​releases+  * Scenario ​availabilty
-    * Frequently (once per month) ​release ​scenarios (i.e. publish results of deployment and testing) ​which are ready (i.e. pass the release ​criteria)+    * Frequently (once per month) ​make completed ​scenarios ​available ​(i.e. publish results of deployment and testing). 
 +      * //Note: This is confusing, to whom is it published and to whom is this release ​targeted from a scenario every month? ​ The monthly scenarion schedule seems unneccessary,​ scenario'​s can be available when they are available without needing to establish a schedule.//
     * Scenario schedules work in parallel to macro OPNFV release schedule     * Scenario schedules work in parallel to macro OPNFV release schedule
-    * Scenario ​releases ​fold into the next OPNFV release+    * Completed ​Scenario fold into the next OPNFV release: All scenarios which are *interested* in joining a release and are *ready* (i.e. scenarios deploy, test results are accepted, documentation is available) participate in a release.  
 +      * Scenarios which participate in a release commit to also maintain the released status (i.e. create a stable branch and maintain the branch until the next release) 
 +        * This includes aligning with the maintenance planning for all associated and dependent projects. (installer, test project release and maintenance plans etc...) 
 +      * "​Experimental scenarios":​ Scenarios can choose to not participate in a release (e.g. scenario is to only provide feedback at a given point in time to upstream project and does not intend to maintain a particular composition longer term. This could e.g. be the case for a test scenario is being stood up to figure out a particular integration - and once stable, the scenario would be merged with an already existing scenario).
  
- +  * Any scenario that intends to participate in a release needs to fulfill the timeline requirements associated with that release. 
-  * Scenarios have their own independent schedules, though ​all of them will define the following milestones.  +  * Scenarios ​that will not participate in OPNFV releases can have their own independent schedules. Though ​all of them will define the following milestones.  
-    * **Feature complete:** All features for a scenario are code complete. Unit tests are successful +    * **Feature complete:** All features for a scenario are code complete. Unit tests are successful. For scenarios which participate in a release, the "​feature complete"​ milestone can be a global OPNFV release milestone. 
-    * **Installation ready:** Features and components for a scenario can be deployed using one of the installers. Integration into at least one of the installers is complete.+    * **Installation ready:** Features and components for a scenario can be deployed using one of the installers. Integration into at least one of the installers is complete. For scenarios which participate in a release, the "​installation ready" milestone can be a global OPNFV release milestone.
     * **Test ready:** Test infra and Test cases for system level testing of features available and code complete.     * **Test ready:** Test infra and Test cases for system level testing of features available and code complete.
     * **Integration ready:** Combination of components in scenarios work “as designed”     * **Integration ready:** Combination of components in scenarios work “as designed”
     * **Release ready:** Test runs complete, documentation ready etc.      * **Release ready:** Test runs complete, documentation ready etc. 
  
 +==== OPNFV releases and scenario availability ====
 +
 +
 +  * An OPNFV release consists of a set of scenarios which are "ready for release"​.
 +  * The Genesis project defines a common baseline for install-features and user-experience for a particular release. Through the Genesis project a common denominator across different deployments for a particular release is ensured.
 +  * OPNFV releases have a set of milestones - some of which they share with scenarios which provides some level of synchronization between scenario editions and OPNFV releases. Note that a complete synchronization of milestones isn't desirable, because it would lead to global synchronization and thus the slowest scenario or component would determine the overall speed (Brahmaputra already departed from a monolithic, fully synchronized release process). Global milestones could include:
 +    * Release planning complete
 +    * Scenarios definition (that desire to participate in the release) complete
 +    * Features code freeze
 +    * Installer code freeze
 +    * Test tools code freeze (differs from "test ready" which freezes the unit/system tests)
 +  * Milestones like "test ready",​ "​integration ready",​ "​release ready" are per scenario milestones.
 +
 +{{:​releases:​scenario-releases.png?​nolink |}}
  
 ===== Release Schedule Discussion (needs updating) ===== ===== Release Schedule Discussion (needs updating) =====
 +
 +**NOTE: The following needs to be updated to reflect individual scenario releases and how they fold into OPNFV releases.**
  
 ==== 1) Set release milestones ==== ==== 1) Set release milestones ====
releases/releaseplanning.1458577015.txt.gz · Last modified: 2016/03/21 16:16 by Frank Brockners