Kanban board

https://jira.onap.org/secure/RapidBoard.jspa?projectKey=CPS&rapidView=228

CPS Team Way-of-Working

1. User Stories are groomed by team in weekly meeting or on demand as required
   1. The label 'Groomed' will be added when the team agrees there is enough information in the ticket, the scope is clear and acceptance criteria are defined
   2. Grooming is not compulsory for Jira (sub)tasks (not affecting source code)
2. Backlog should be in priority order.
   1. Check bugs first, unless specially agreed they always have the highest priority 
   2. Check the next available user story is 'Groomed' and there are no blocking dependencies
      1. if it not groomed but seems to be next in line, call a quick meeting with PTL and available team members to groom it as soon as is practical
   3. Check with PTL if story can be taken as there could always be last minute updates or changes that might prioritize a different task
   4. Inform team about you intention to take user story
   5. Assign user story to yourself
   6. Set user story to In progress! (even if starting with some study first)
   7. If required (typically agreed during grooming) create a Implementation Proposal page here:  Implementation Proposals
      1. You might find a proposal  is needed anyway and help you code and share intention for code solution with team and or address specific issues that are discovered during implementation phase
      2. Implementation Proposals are also good for knowledge sharing with the team and a quick meeting about it might be required depending on the nature of the user story
      3. Implementation Proposals can also serve as permanent developer documentation and might require further addition e.g. for CPS Exceptions and REST API HTTP Response Codes
   8. Sub task(s) can be created to track the work (especially for larger user stories) and/or delegate but this is optional
3. Commit early and frequently
   1. It is always good to give the team a heads up and share early!
   2. The WiP flag in Gerrit can be used to indicate that review is not ready for review with a fine toothcomb yet
4. All java code commits should be accompanied with test ware covering the new or modified code (unless agreed by team to handle it in a separate commit in special circumstances) 
5. Review quick and fast, none of us like context switching but we cant have developer sitting and waiting for reviews either, try to balance this!
6. Depending on the user story a demo might be required before it can be closed
   
   1. Demos should be recorded and added to CPS User Story Demos

Code, Merge requirements and Jira updates are further detailed in next few sections

JIRA Status Updates

Committer Strategy

• Each review requires 2 committers to +1 and/or +2.
• A +2 from committer or PTL have the permissions to merge code.
• See also Committer Best Practices

Merge and +2 committers:

• Rishi Chail
• Former user (Deleted)
• Toine Siebelink

Code Requirements

1. Copyright included in each file.  Apache 2 for coding files.
   1. The Copyright line for contributing organization inserted or updated reflecting the contribution year.
2. A LICENSE.txt file placed at the root of the repo to provide umbrella coverage.
3. Unit testing coverage > 90% using Persistence Layer Testing and  Groovy & Spock
4. We will follow ONAP Recommended Software Development Best Practices: Developer Best Practices
5. Setting Up Your Development Environment details a general set up for ONAP projects. Please note the CPS Specific requirements below!

CPS Specific Code Style set up

• InteliJ IDE: As we have noticed some slight formatting issues that are not controlled by the IDE we prefer that CPS contributors use IntelliJ (community edition is perfectly good for Java development)
• CPS CheckStyle Scheme: CPS as extended the standard ONAP CheckStyle configuration. Once you have downloaded CPS you can find the definition in <your_git_folder>checkstyle/src/main/resources/cps-java-style.xml
• Groovy: CPS uses Groovy/Spock for unit testing. There is some additional formatting setup to ensure consistent formatting of Groovy files.

Configure CPS code CheckStyle Plugin for IntelliJ

1. Select, File, Settings, Tools, Checkstyle  
2. Click on + beside the 'Configuration File' box to add a configuration
3. Set description to something like 'ONAP Rules'
4. Click on Browse to select the file <your_git_folder>checkstyle/src/main/resources/cps-java-style.xml
5. Complete the Wizard (you can set exclusion properties if needed)
6. Activate the Configuration File you just added by selecting the relevant checkbox
7. optional: Click [OK] to close the settings popup

Configure CPS code style auto formatting for IntelliJ (using the same CheckStyle rules and automating it for you )

1. Select, File, Settings, Editor, Code Style
2. Click on the gear icon at the end of the line for "Scheme:"
3. Optional: As importing a schema overrides the current scheme you might want to first use the 'Duplicate..' and  'Rename...' options to create an easily identifiable scheme e.g. 'CPS Standard'
4. Import Scheme→Checkstyle Configuration
5. Click on Browse to select the file  <your_git_folder>checkstyle/src/main/resources/cps-java-style.xml
6. optional: Click [OK] to close the settings popup

Configure CPS Java code style auto formatting for IntelliJ

1. Select, File, Settings, Editor, Code Style, Java
2. Ensure the same scheme is selected (as suggested in step 3 in the previous instructions: 'CPS Standard')
3. Select 'Tabs and Indents' tab
4. Set 'Tab size' to 4
5. Set 'Indent' to 4
6. Set 'Continuation indent' to 8
7. Set 'Label indent' to 0
8. Select 'Imports' tab
9. Set 'Class count to use import with '*'' to 999
10. Set 'Names count to use static import with '*'' to 999
11. Click [OK] to close the settings popup

Configure CPS Groovy code style auto formatting for IntelliJ

1. Select, File, Settings, Editor, Code Style, Groovy
2. Ensure the same scheme is selected (as suggested in step 3 in the previous instructions: 'CPS Standard')
3. Select 'Tabs and Indents' tab
4. Set 'Tab size' to 4
5. Set 'Indentt' to 4
6. Set 'Continuation indent' to 8
7. Set 'Label indent' to 4
8. Select 'Imports' tab
9. Set 'Class count to use import with '*'' to 999
10. Set 'Names count to use static import with '*'' to 999
11. Click [OK] to close the settings popup

Code Submissions

• Any CheckStyle issues must be fixed in current review.
• Code must be covered by tests.
• We are currently in the process of setting up sonarqube to check our code coverage. Please use the sonarqube plugin for now to measure coverage. To setup sonarqube see dev setup guide: Setting Up Your Development Environment#LocalSonarQubeSetup
• Mark the review as WIP if it is not ready for review. 
• Commit message must be in the following format: 

Code Analysis

We recommend that most user stories are accompanied with  small wiki page to document/clarify some analysis for that user story.

See Implementation Proposals

Unit Test

CPS is promoting Groovy and Spock for our unit test. All new modified code should include good quality test

see Groovy & Spock you can also contact the PTL Toine Siebelink for more details

User Story Demos

As part of our best practice to finish a user story it should be demonstrated to team and if possible recorded

see CPS User Story Demos

Jenkins Job 

ONAP uses Jenkins based CICD tool chain.  However, contributors are only given read access to the Jenkins servers.  All jobs are created by automatic generation from JJB definitions. 

https://jenkins.onap.org./view/cps/

Bug reporting

https://jira.onap.org/secure/RapidBoard.jspa?rapidView=228&projectKey=CPS&view=planning&issueLimit=100

Vulnerability report process

If you find any vulnerability please email the security contact with the information that you have.

The security contact is ; toine.siebelink@est.tech

We will give credit to anyone who reports a vulnerability so that we can fix it. If you wish to remain anonymous instead, please let us know and we will respect that.

Documentation

https://docs.onap.org/en/latest/index.html