get_started:release_and_maintenance
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
get_started:release_and_maintenance [2015/05/06 14:56] Frank Brockners created |
get_started:release_and_maintenance [2015/05/06 17:57] Daniel Smith |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Terminology discussion: "Release", "Latest", etc. ====== | ====== Terminology discussion: "Release", "Latest", etc. ====== | ||
| - | * **Release** | + | * "**Release**" |
| - | * OPNFV defined fixed set of objects and artifacts. All objects and artifacts are **specifically versioned**: Using the versions it must be possible to reproduce the "release" for as long as the "release" is supported by OPNFV (i.e. not deprecated). | + | * OPNFV defines a "release" as a fixed set of objects and artefacts marked at a specific point in time that will be supported as such. All objects and artefacts are tagged with a unique/specific version: Using the version it is possible to reproduce the "release" for as long as the "release" is supported by OPNFV (i.e. not deprecated). |
| - | * The "release" successfully deploys on a set of reference hardware/infrastructure (see below for "reference hardware"). Successful deployment means that all tests defined for a particular release pass. | + | |
| - | * OPNFV defined set of scenario tests associated with the release | + | * The purpose of a release is to allow a consumer to use the object(s) in the course of a successful "deployment". A success deployment is defined as an "installation system based from a version release that satisfies all the criteria (tests) in terms of pass/fail. Its important to understand that the term "deployment success" can be subjective depending on end-users' expectations and environments, however in OPNFV we related back to our Reference Topology and Reference Environments with regards to testing and acceptance. |
| + | |||
| + | * OPNFV delivers a set of scenario tests associated with the release that are traceable back to the Function Test Suite for that specific build/release. | ||
| + | |||
| * Release content: | * Release content: | ||
| - | * Bootable disk image (ISO) to install the jump host | + | * Bootable disk image (ISO) used to install a Jumpstart Server |
| - | * Build script which allows the creation of the above mentioned ISO | + | * Deployment tool that allows a user to perform autodeployment of the "release ISO". This deployment tool will allow the end-user to point to a specific patch-id/branch within OPNFV Gerrit so that the autodeployment is using the same artefacts as was used to generate the release ISO. |
| - | * Option: Deploy script which creates an equivalent installation of what the bootable disk image (ISO) creates. | + | |
| * Description of the reference hardware and its configuration that the code was tested on | * Description of the reference hardware and its configuration that the code was tested on | ||
| - | * Description of all components/artifacts used in the release, including their individual versions (and if applicable, a reference to where these artifacts are sourced from). | + | * Description of all components/artefacts used in the release, including their individual versions (and if applicable, a reference to where these artefacts are sourced from). |
| - | * Documentation (installation and user-guide, release notes, licenses used, etc.) | + | * Documentation (installation and user-guide, release notes, licenses used, etc.) specific that release. |
| - | * Description of the tests performed along with the test results. | + | * Description of the tests performed along with the test results (pass/fail/skipped). |
| - | * Approved by the TSC to be an official release of OPNFV | + | * Approved by the TSC to be an official release of OPNFV with appropriate "Release Report" ensuring all "release criteria" (defined herein) has been met. |
| * Community supported: Collections of bug-fixes etc. will be supplied as a "maintenance release" (see below), which has the same qualities as a "release". | * Community supported: Collections of bug-fixes etc. will be supplied as a "maintenance release" (see below), which has the same qualities as a "release". | ||
| - | * **Maintenance release** | + | * "**Maintenance release**" |
| - | * Fixed set of objects and artifacts defined by a specific existing (i.e. already released) OPNFV release. | + | * Fixed set of objects and artefacts defined by a specific existing (i.e. already released) OPNFV release. |
| - | * The "maintenance release" successfully deploys on a set of reference hardware/infrastructure (see below for "reference hardware"). Successful deployment means that all tests defined for a particular release pass. | + | * The "maintenance release" successfully deploys on a set of reference hardware/infrastructure (see below for "reference hardware"). Successful deployment means that all tests defined for a particular release pass (i.e Regression testing to ensure the Maintenance Release does not break additional things). |
| - | * "Maintenance release" content is the same as that of a "release". | + | * "Maintenance release" content is the same as that of a "release" with the corrected features / functions |
| + | * A Delta Report/Change Report outlining the differences between "Main Release" and subsequent Maintenance (Service) Releases. | ||
| - | * **Latest** | + | * "**Latest**" |
| - | * Fixed set of objects and artifacts defined by a specific OPNFV release (existing //or// planned). Rather than using a specific version of a particular component, the latest available components (could be binary artifacts or sources) from upstream repositories are used. | + | * Fixed set of objects and artefacts defined by a specific OPNFV release (existing //or// planned). Rather than using a specific version of a particular component, the latest available components (could be binary artefacts or sources) from upstream repositories are used. |
| - | * The "latest" successfully deploys on a set of reference hardware/infrastructure (see below for "reference hardware"). Successful deployment means that all tests defined for the particular release (existing or planned) pass. | + | * The "latest" successfully deploys on a set of reference hardware/infrastructure (see below for "reference hardware"). Successful deployment means that all tests defined for the particular release (existing or planned) pass. Main objective of "latest" is to give developers and testers immediate feedback at system level. |
| * OPNFV defined set of scenario tests associated with the release | * OPNFV defined set of scenario tests associated with the release | ||
| * "Latest" does not imply a “supported” release, rather is the “latest” working merge working towards the next target ‘release’ (future or maintenance) from OPNFV. | * "Latest" does not imply a “supported” release, rather is the “latest” working merge working towards the next target ‘release’ (future or maintenance) from OPNFV. | ||
| * Does not imply anything more than Jenkins smoke-test and may/may not work (Users should be aware) | * Does not imply anything more than Jenkins smoke-test and may/may not work (Users should be aware) | ||
| - | * **Reference hardware/infrastructure** | + | * "**Reference hardware/infrastructure**" |
| * Set of infrastructure to deploy an OPNFV release on (used for validation purposes) | * Set of infrastructure to deploy an OPNFV release on (used for validation purposes) | ||
| * Documentation of | * Documentation of | ||
| Line 34: | Line 37: | ||
| * Setup (cabling etc.) of the hardware | * Setup (cabling etc.) of the hardware | ||
| * Configuration of the hardware and any associated software (e.g. management systems etc.) | * Configuration of the hardware and any associated software (e.g. management systems etc.) | ||
| + | |||
| + | * The purpose of a Reference Hardware is to provide a basis for end-users to development their own environments from and should not be interpreted as the "rule". Rather its a reference to establish a working release from, provide transparency to the methods and ways in which a "release" was established and a baseline for which to compare further releases, maintenance releases and other features against. Not meant to be exhaustive. | ||
| + | |||
| + | |||
| + | * "** Use of Releases / Maintenance Releases / Latest **" | ||
| + | * As outlined above, this document is intended to provide a common-ground for terminology usage both within the OPNFV development community as well as for the consumers of the OPNFV production so that everyone has a common understanding and agreement of what we mean. | ||
| + | * From a Consumer Standpoint, the intention is that a end user will obtain what OPNFV produces (whether it be via a simple ISO, autodeployment from a tool, or fetching and building their own (in the case of "latest") and use the appropriate corresponding documentation to make use of that 'production'. | ||
| + | |||
get_started/release_and_maintenance.txt · Last modified: 2015/05/06 17:57 by Daniel Smith
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
