This is a high level draft process for use case integration. Do not hesitate to comment/amend/criticise/improve/..)
Historically Integration is in charge to help and support use case projects.
The use case projects define their architecture, test plans, deal with the component projects when changes/features are needed.
We may consider the integration in several steps
| Step | Description | Expected results | Integration team role | Documentations | Comments |
|---|---|---|---|---|---|
| 1 | use case runnable in 1 lab | The use case is up&running in 1 lab, that can be the use case owner lab - The result is declarative trusted by default, included in the use case wiki page managed by the integration team | if resources needed, windriver lab can be used to. A request shall be addressed to the Integration team by mail or during weekly meetings Support is also provided in best effort by Integration contributors | wiki documentation is acceptable | The use case is considered as "draft" and cannot be announced as officially part of the release |
| 2 | Official Documentation is available | Based on 1), an official documentation is provided (in integration repository). Documentation is sufficient to allow people to replay the use case in another lab. | review/merge the documentation pushed into integration repository | official documentation mandatory | The use case is considered as a "candidate use case" and can be announced for the release. |
| 3 | use case runnable in at least 2 labs | Based and 1 and 2) the use case has been deployed in another lab | Integration team can help to re-run the test in a lab from the Integration community and support the test from a second source. At this stage automation shall be initiated to simplify the deployment and execution of the tests | tooling and automation scripts must be documented. It is highly recommended for each tooling to include code verification, and unit tests (same quality rules than the component developments) | it may be include in the gate in candidate use case stage (if the use case is easy to automate). |
| 4 | integration in testing gate | The use case is included in smoke or candidate use case stage, these stages are run on Daily CI chains. Results are automatically reported from 1 or several labs. The use case must be deployable/runnable in 1 click and include its own resources setup and tear down independently from the installation | Integration team can help to integrate the use case in the CI chains | Declare use case in test DB http://testresults.opnfv.org/onap/api/v1/projects/integration/cases http://testresults.opnfv.org/onap/api/v1/projects/security/cases | The use case is considered as a "smoke use case", it means that it is part of the criteria for the release. It must be PASS in the gate. |
Note: 4 is not always possible. If you are using proprietary/physical equipments and/or VNFs and/or complex use cases, it may be hard to automate and push in gate. If the test is also very long, it may be excluded to save CI resources.