This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
releases:releaseplanning [2016/03/21 16:10] Frank Brockners |
releases:releaseplanning [2016/03/22 20:33] Frank Brockners |
||
---|---|---|---|
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 releases.}} (presented at OPNFV Hackfest, Santa Clara, March 14-15, 2016). |
+ | |||
+ | ==== 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 | ||
+ | * This is a unique value OPNFV provides to component/feature developers, who can typically only run unit tests | ||
+ | * OPNFV scenarios provide rapid feedback to developers | ||
+ | * The faster the results of a scenario become available, the higher the value to a component developer | ||
+ | * Providing system-level test-results quickly to (upstream) developers, allows for more rapid innovation and increases the relevancy of OPNFV to developers of components | ||
+ | * Accommodate for the fact that not all scenarios are created equal (some are complex, some are simple) | ||
+ | |||
+ | ==== Scenario-based release coordination: Approach ==== | ||
+ | |||
+ | * Per scenario schedules | ||
+ | * Not all scenarios are of the same complexity: Allow for per scenario schedules; allow scenarios to define their own schedule | ||
+ | * Scenario availabilty: | ||
+ | * 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 | ||
+ | * 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 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. 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. 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. | ||
+ | * **Integration ready:** Combination of components in scenarios work “as designed” | ||
+ | * **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 ==== |