ONAP DCAE Designtime

https://git.onap.org/dcaegen2/platform/tree

Tracking is provided by using a combination of JIRA and git history. Every commit has an user and a Jira number attached to it.

Gerrit provides an temperate branch for reviewing and providing comments. Once approved, the code will be merged and the temperate branch will be removed.

Git and and its code review add-on Gerrit are used.

Release version is with format ${major}.${minor}.${patch} and will be updated accordingly for each release.

Each release is tagged within the Gerrit repository.

Release notes include as part of DCAE documentation. For example, R1 release notes can be found at: http://onap.readthedocs.io/en/amsterdam/submodules/dcaegen2.git/docs/sections/release-notes.html#id1

The latest release notes for ONAP projects can be found at: https://docs.onap.org/en/latest/release/releaserepos.html#doc-releaserepos. The known vulnerabilities are reported under the "Known issues" and "Security Issues" sections.

The description of the process can be found in the following URL: https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA

Jira is used to track issues. https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA

The reported issues are being handled as soon as possible.

The reported issues are being handled as soon as possible.

All ticket reporting and commenting are available on https://jira.onap.org. The Git/Gerrit system enforces a submission gating function that any code change must include a JIRA Issue ID, which the corresponding JIRA ticket's page links as part of progress report.

The process on how to report a vulnerability can be found in https://wiki.onap.org/display/DW/ONAP+Vulnerability+Management

The process on how to report a vulnerability can be found in ONAP Vulnerability Management https://wiki.onap.org/display/DW/ONAP+Vulnerability+Management.

By default all vulnerability reports are private unless modified by the reporter.

Jenkins is used for building all software components (e.g. jar, war, pypi wheel packages) as well as docker images: https://jenkins.onap.org.

Maven, pip, are used to build software components (jar, war, wheel, etc). Docker is used to build software packages (docker container image)

Maven and docker are under Apache 2.0. Pip is licensed under MIT.

Junit (under EPL) for Java and Clojure components.
Pytest (under MIT) for python projects.
Rebar3 (under Apache 2) for Erlang code. Robot Testing Framework (under Apache 2) for docker container level testing.

Junit tests are invoked from mvn. Pytest tests are invoked by running pytest from command line. Rebar3 tests are invoked from command line by running rebarr3. All are included as part of Jenkin builds. All are standard testing tools invoked in standard way. Robot Framework tests are invoked by standard Robot methodology, also triggered by Jenkins build jobs. https://wiki.onap.org/display/DW/Continuous+Integration https://wiki.onap.org/pages/viewpage.action?pageId=4718718

The combination of Junit/pytest/rebar3, and robot testing framework has the ability to cover all the branches and input fields

For each pull request, the project needs to be built successfully before the Merge option becomes activated. The test will be run automatically during the building process as well. Once build successfully and all tests has past, the Merge option will be activated.

https://wiki.onap.org/display/DW/Continuous+Integration https://wiki.onap.org/pages/viewpage.action?pageId=4718718

ONAP uses Robot testing framework for automated integration test. Passing CSIT test cases is a requirement for passing code freeze mile stone: https://wiki.onap.org/display/DW/Deliverable+for+Code+Freeze+Milestone+Checklist+Template , under "Integration and Testing".

CSIT test results available on jenkins build result reporting: https://jenkins.onap.org/view/CSIT/

This is documented on our wiki on Code Coverage and Static Code Analysis: https://wiki.onap.org/display/DW/Code+Coverage+and+Static+Code+Analysis and https://wiki.onap.org/display/DW/Creating+a+CSIT+Test

style check, SONAR reporting, and CLM scanning

MOD submission are reviewed/approved based on verify build report - https://jenkins.onap.org/view/dcaegen2-platform-mod/ This project is also in POC/inbuation phase; as it becomes more mature - more strict enforcment to be added.

MOD submission are reviewed/approved based on verify build report - https://jenkins.onap.org/view/dcaegen2-platform-mod/ This project is also in POC/inbuation phase; as it becomes more mature - more strict enforcment to be added.

At present time, majority of DCAE components are contributed by developers from AT&T. AT&T developers are generally familiar with secure software development practice and experienced in vulnerability resolution because of their internal practice of using Fortify SCA tool from HP.

At present time, majority of DCAE components are contributed by developers from AT&T. AT&T developers are generally familiar with secure software development practice and experienced in vulnerability resolution because of their internal practice of using Fortify code analysis tool from HP.

MOD components are not sourced as libraries

TLS for secure API calling.

The DesignUI does not support currently username/authentication

HTTPS is used to download all ONAP artifacts, and some are signed by the Linux Foundation.

There are several instances of passwords included in the public repos of DCAE as part of the testing/demo deployment configuration.
They serve as examples for setting up functional demonstrations, and not intended to limit public access.

Sonatype CLM scan is applied for static code and dependency security vulnerability reporting. Its results are available on https://nexus-iq.wl.linuxfoundation.org/assets/index.html. Language specific unit testing is mandatory for all ONAP projects. Results are reported to SONAR server.

Sonatype CLM scan is applied for static code and dependency security vulnerability reporting. Its results are available on https://nexus-iq.wl.linuxfoundation.org/assets/index.html. The reports contained details of the vulnerabilities and suggestions of fixes.

The CLM scan is triggered by key-word command in the Gerrit review system. It is applied by PTL and committers after new code changes are merged into the system.

DCAEGEN2 components are implemented in Java, Shell and Python. Not using C or C++.