遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/2147)
<a href="https://www.bestpractices.dev/projects/2147"><img src="https://www.bestpractices.dev/projects/2147/badge"></a>
DMaaP Databus Controller API provides a provisioning API for clients of the data movement services (MR and DR) available in ONAP. This API will create topics or feeds for clients who need to publish or subscriber.
https://wiki.onap.org/display/DW/Development+Procedures+and+Policies
The Java code should meet the requirement of Google Java Style - https://google.github.io/styleguide/javaguide.html except indents are 4 spaces and column limit is 120 which is described here: https://wiki.onap.org/display/DW/Java+code+style Developer Best Practices: https://wiki.onap.org/display/DW/Developer+Best+Practices
ONAP requires both a Developer Certificate of Origin (DCO), and a Contributor License Agreement (CLA).
https://wiki.onap.org/display/DW/Contribution+Agreements e.g. of signed-off commit: https://gerrit.onap.org/r/#/c/66789/
The project governance is described at
https://wiki.onap.org/display/DW/Community+Offices+and+Governance
Further information can be found at https://wiki.onap.org/display/DW/ONAP+Technical+Community+Document
https://lfprojects.org/policies/code-of-conduct
The key roles in the project and their responsibilities are described at
Current members are listed at
https://wiki.onap.org/pages/viewpage.action?pageId=8226539
For dbcapi we have 2 committers and multiple contributers who are listed in https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-DataMovementasaPlatform All 2 committers have access and rights to maintain the code base, approve and review incoming changes and release a new version of the artifact. This will let the project continue with minimal to no interruption if one person is incapacitated. Also this project is controlled by the linux foundation so we can add more committers if needed
All the projects covered in this report have more than 2 persons who actively contribute and maintain code. The following links provides with list of commit owners for the project which list at least two or more individuals: https://gerrit.onap.org/r/#/q/project:dmaap/dbcapi+branch:master https://gerrit.onap.org/r/#/q/project:dmaap/buscontroller+branch:master
https://wiki.onap.org/display/DW/DMaaP+Roadmap
Documentation is updated with each release.
The badge is visible on the project's page here: https://wiki.onap.org/display/DW/Data+Movement+as+a+Platform+Project
The DMaaP Buscontroller project does not have any user interface. It exposes an API and fulfills a contract: https://gerrit.onap.org/r/gitweb?p=dmaap%2Fdbcapi.git;a=shortlog;h=HEAD https://gerrit.onap.org/r/gitweb?p=dmaap%2Fbuscontroller.git;a=shortlog;h=HEAD
The project does not store passwords for authentication of external users
All major releases are tagged in gerrit and the artifacts are stored with the release information on onap.nexus. So we can access all old versions of the artifact. If and when a upgrade requires certain steps to be followed they are being added to the release documents as needed
Jira is used to track issues: https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA
Vulnerabilities can be reported using the link https://wiki.onap.org/pages/viewpage.action?pageId=6591711 Currently we dont have any vulnerabilities reported, but the wiki page explains on how to report a vulnerability and how to report anonymously if you do not want the credit for it.
Vulnerabilities handling is documented in: https://wiki.onap.org/pages/viewpage.action?pageId=6591711
Project uses Google Java Style with changes explained here - https://wiki.onap.org/display/DW/Java+code+style
The application does not create native binaries as it creates a jar.
All releases are tagged in gerrit(git), and the builds are controlled using jenkins. By providing the git tag information the same image can be build over and over again with same bit-for-bit result.
All packages are delivered either as an jar artifact or a docker image. In case of maven artifacts, they can be removed using the pom file. In case of docker container. We can delete the container we dont want. Also control the orchestration in Kubernetes if you want to exclude certain docker images.
The compiled docker images and jar files can be installed/used as the user sees fit. Both run on JVM or docker. So there is no reason to selecting locations etc.
The component requires only java and maven to begin with for a developer to quickly install and test it. Even for deployment using OOM and the right amount of resources, we can deploy the full DMaaP/ONAP suite in less than a day. The steps are documented in https://onap.readthedocs.io/en/latest/submodules/oom.git/docs/oom_quickstart_guide.html
External dependencies are controlled using the pom file, which can be found in the root folder of each of the projects modules: https://gerrit.onap.org/r/gitweb?p=dmaap/dbcapi.git;a=blob;f=pom.xml;h=ece7ae0bf8c6f9cd36f7603d5ff89e6c22c5ef60;hb=c9016e789222c9512d484f296795ffa0a16bd7d7 https://gerrit.onap.org/r/gitweb?p=dmaap/buscontroller.git;a=blob;f=pom.xml;h=5a2d435edc0cb7f9ac1642a646796c8d5a5108fa;hb=53eef7bbc76b4443877e5ab4a1bd10083335e41e
NexusIQ sonar scan is run on the project on a weekly basis: https://jenkins.onap.org/view/CLM/job/dmaap-dbcapi-maven-clm-master/ https://jenkins.onap.org/view/CLM/job/dmaap-buscontroller-maven-clm-master/
External components are maintained through Maven. The user can get a list of all included components using the maven dependency tree and can update or reuse as they see fit
Automatic test suites are run every time before merging the code. The code check in cannot pass without jenkins posting a +1 on the review. https://jenkins.onap.org/view/dmaap/job/dmaap-buscontroller-master-verify-java/ https://jenkins.onap.org/view/dmaap/job/dmaap-dbcapi-master-verify-java/
When regressions occur, we add tests for them.
We use sonar to measure the code coverage. https://sonar.onap.org/about Code coverage at the date of filling this report(2018-10-23) is: dbcapi: 52.2% line coverage
Contributing guide lines for development is recorded in: https://wiki.onap.org/display/DW/Development+Procedures+and+Policies
Documented in ONAP wiki here: https://wiki.onap.org/display/DW/Code+Coverage+and+Static+Code+Analysis
Build systems run the compile with test flag enabled by default. So any failure in test cases will fail the ci and the merge request.
The project strives to implement secure design principles.
All generated certificates are generated with sha256
Certificates are managed through AAF micro-service which will be deployed with ONAP suite
The projects supports secure TLS and HTTPS and insecure protocols are disabled by default in these applications, they can be over-ridden by user configuration
The products support TLS version 1.2
Certificate validation is done before answering any calls.
The certificate is validated before sending http headers or private information.
All release artifacts are signed by the Linux Foundation prior to release.
The project strives to validate all input to functions. The inputs that are provided to the services are checked against existing models such as OXM or search-abstraction layer and only valid inputs are allowed to be pass through
The project tries to use hardening mechanism whenever possible. Eg we use transaction id for tracking transactions through multiple services and also we use http headers to identify the application where possible
Rules used - https://sonar.onap.org/coding_rules#languages=java
The code is written in Java, which is a memory-safe language
后退