Differences

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

--- releases:releaseplanning [2016/03/07 01:18]
julien zhang [Table]
+++ releases:releaseplanning [2016/03/22 20:34] (current)
Frank Brockners [Release Structure for Colorado (Proposal)]
@@ Line 1: / Line 1: @@
 ====== OPNFV C release planning activities ======
+===== Release Structure for Colorado (Proposal) =====
+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 editions.}} (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) =====
+**NOTE: The following needs to be updated to reflect individual scenario releases and how they fold into OPNFV releases.**
 ==== 1) Set release milestones ====
 We need to quickly establish our key milestones for C-Release in order that projects are able to establish their scope and intentions for the release.
-^  MS#  ^  Timeline  ^  Offset 1  ^  Offset 2  ^  Target                                      ^
+^  MS#                   ^  Timeline  ^  Target                                      ^
-| MS1   | 8/March    | 8/March    | 8/March    | Projects indicate intent toward the release  |
+| Project planning start | 8/March    | Projects indicate intent to participate in the release  |
-| MS2   | 8/April    | 15/April   | 15/April   | Close project inclusion and establish plans  |
+| Planning complete      | 8/April    | Close project inclusion and plans are established  |
-| MS3   | 12/July    | 19/July    | 26/July    | Close project development phase - freeze     |
+| Feature Code freeze    | 31/Mai    | Close feature project development phase - freeze     |
-| MS4   | 16/August  | 16/August  | 16/August  | Project release                              |
+| Installation Code freeze | 21/June    | Installer/plugins code complete     |
+| Test Code freeze    | 28/June    | Test infra and scenario tests complete |
+| Integration ready   | 26/July    | Scenario integration complete  |
+| Release                | 16/August  | Release |
 ==== 2) Establish milestones expectations ====
@@ Line 15: / Line 78: @@
 With clear milestone dates we should work to establish the expectations on project for those milestones.  The intention of this work is to ensure we have key activities done during the project work and not after code freeze.
-MS1.
+MS0 : Project planning
-  * State your intention to participate in the C-Release
+  * Activities to be performed during this phase:
-  * Define impacts on other projects;
+    * State your intention to participate in the C-Release
-    * installers
+    * establish release plan wiki /projects/<projectame>/releaseplan
-    * test projects
+    * Define impacts on other projects;
-    * documentation
+      * installers
-    * Infrastructure (pharos/CI)
+      * test projects
-  * Include estimated time and resource plans
+      * documentation
-MS2.
+      * Infrastructure (pharos/CI)
-  * Have coordinated schedules with other projects and captured cross project dependencies in Jira.
+    * Include estimated time and resource plans
-  * Have a concrete project time plan in place that accommodates dependencies and resource availability
+    * Project plans in place in Jira (at the story level and cross project)
-  * Dependencies must include upstream dependencies impacting ability to execute on future milestones
+MS1 : Planning complete
-MS3.
+  * Project must
-  * Must be code complete.
+    * Have coordinated schedules with other projects and captured cross project dependencies in Jira
-  * Must have successfully deployed expected deliverables on a pharos lab
+    * Have a concrete project time plan in place that accommodates dependencies and resource availability
-  * Have completed test case development
+    * Dependencies must include upstream dependencies impacting ability to execute on future milestones
-  * Have documentation in place for pre-release verification
+  * Activities to be performed after this milestone
-  * Begin release readiness activities and verification.
+    * Development of feature code
-    * Stable branch labels can be applied from here.
+    * Integration in, or establishment of, scenario's
-MS4.
+    * Test case development
-  * All frozen features and scenario's have achieved release readiness.
+MS2 : Feature Code freeze
-  * All stable branch labels in place, release labels available on the branch.
+  * Feature project must
+    * Be code complete.
+    * Have completed unit test case development
+    * Have documentation in place for pre-release verification
+  * Activities to be performed after this milestone
+    * Begin release readiness activities and verification.
+      * Stable branch labels can be applied from here (project to decide when to pull the stable branch).
+MS3: Installation Code freeze:
+  * Installers code complete / code freeze
+  * Features successfully deploy expected deliverables on a pharos lab
+  * Feature/component installs with target installer(s), i.e. plugins or similar for the installers are ready.
+MS4: Test Code freeze
+  * Test infra and Test cases for system level testing of features available and code complete.
+MS5: Integration ready:
+  * Combination of components in scenarios work "as designed".
+MS6 : Release
+  * Project must
+    * All frozen features and scenario's have achieved release readiness.
+    * All stable branch labels in place, release labels available on the branch.
+  * Activities to be performed after this milestone
+    * Clear plans for release support according to the release stable processes
 ==== 3) Definition of the development process ====
@@ Line 51: / Line 134: @@
 This may be as in Brahmaputra where each project implemented an own project development practice.
 If such a process is used there needs to be clear directives on milestone deliverables that the projcts are expected to align toward in order to better manage the development effort involved in providng platform feature availability.
+==== 4) Related Links ====
+[[https://etherpad.opnfv.org/p/c-release-brainstorming | release-c-brainstorming]]
+[[release_c_planning/priority_list |release-c-priority_list]]
 More...

Wiki

User Tools

Site Tools

Differences

Page Tools