...
Practice Area | Checkpoint | Yes/No | Evidences | How to? | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Architecture | Has the Project team reviewed the APIs with the Architecture Committee (ARC)? | 3/6/2018 |
| Architecture walkthrough to understand how each project contributes on Release Use Case. ARC to organize the walkthrough. | ||||||||
Is there a plan to address the findings the API review? | n/aTBD | Link to plan | The plan could be as simple as a Jira issue to track the implementation of findings or a documented plan within the wiki. | |||||||||
Does the team clearly understand that no changes in the API definition is allowed without formal TSC review and approval? | Yes | NA | In the case some changes are necessary, bring the request to the TSC for review and approval. | |||||||||
Is there any changes in the scope, functionalities, deliverable, dependency, resources, API, repositories since M1 milestone? | No | If Yes, please a link to the evidence of these changes. | Critical point to understand is that change is inevitable, and that right timing and clear communication to the community will ease the process of accepting changes. | |||||||||
Provide link to the API Documentation. | Policy API | |||||||||||
Release Management | Are committed Sprint Backlog Stories been marked as "Done" in Jira board? | Yes | https://jira.onap.org/secure/RapidBoard.jspa?projectKey=POLICY&rapidView=15&view=planning | |||||||||
Are all tasks associated with Sprint Backlog Stories been marked as "Done" in Jira? | Yes | |||||||||||
Have all findings from previous milestones been addressed? | n/aNo Previous Findings | Provide link to JIRA findings | ||||||||||
Development | Has the project team reach the Automated Unit Test Code Coverage expectation? (Refer to artifacts available in Sonar) | Yes | Goal: 50% for Incubation project in Beijing | Guidance on Code Coverage and Static Code Analysis | ||||||||
Is there any pending commit request older than 36 Business hours in Gerrit? | No | |||||||||||
Do you have a plan to address by M4 the Critical vulnerabilities in the third party libraries used within your project? | Yes | Policy R2 Beijing Security/Vulnerability Threat Template | Ensure by M4 the Nexus-IQ report from “Jenkins CLM” shows 0 critical security vulnerability. Open the Nexus-IQ report for the details on each repo. | |||||||||
Are all the Jenkins jobs successfully passed ( Merge-Jobs)? | Yes | https://jenkins.onap.org/view/policy/job/policy-common-master-merge-java/ https://jenkins.onap.org/view/policy/job/policy-drools-pdp-master-merge-java/ https://jenkins.onap.org/view/policy/job/policy-drools-applications-master-merge-java/ https://jenkins.onap.org/view/policy/job/policy-engine-master-merge-java/ https://jenkins.onap.org/view/policy/job/policy-docker-policy-master-merge-scm-mvn-script/ Please note that we have 2 additional merge jobs that we are currently debugging as replacements to drools-pdp and engine repositories. Targeting to be completed by official M3 date 3/8/2018. | ||||||||||
Are all binaries available in Nexus? | No | Gildas Lanilis Gmail - should this row be removed as we are not requiring binaries until M4?Yes - SNAPSHOT only | ||||||||||
Integration and Testing | Have 50 % of System Integration Testing Use Cases been implemented successfully in Jenkins? | Yes | https://jenkins.onap.org/view/policy/job/policy-master-csit-health/ | |||||||||
Has the project code successfully passed the Daily Build process? | No (N/A) | Gildas Lanilis Gmail - should this be requirement be removed from M3 checklist? As we are not requiring daily release builds until M4. | Goal is to ensure the latest project commit has not broken the Integration Daily Build |