CPS Team Way-of-Working

A Story/user story is a software system requirement expressed in a few short sentences, using non-technical language. A User Story should express needs from the user's perspective. This can be conveyed in a syntax way like the below illustration

Jira Stories/Tasks are groomed by the team in weekly meetings or on demand as required
User Story Syntax Expression
As a <user> = who
I want to <be able to do ABC> = what
So that <XYZ can be done> = why
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)
3. Select the appropriate release/Fix Version the feature is intended for.
4. Add user stories to relevant epic
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 APIs 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
Commit early and frequently
1. It is always good to give the team a heads up and share early!
2. Ensure the relevant team developers are added as reviewer typically the work-item owner and at least 2 others, see more details on review process below
3. Use the CPS Slack channel to inform the team that a commit is ready for review or re-review once comments have bene implemented
4. The WiP (Work in Progress) flag in Gerrit can be used to indicate that review is not ready for review with a fine toothcomb yet but it can also simply be stated in the commit message
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)
Review promptly, none of us like context switching but we cant have developer sitting and waiting for reviews either, try to balance this!
1. Use Code Review Checklist : CPS Code Review Check List
2. Please review completely ie. it shouldn't be necessary to add more comments on unchanged code after committer as applied your previous comments.
3. Please close any resolve commits using 'Done' option. It is up to the commenter to re-open if they don't agree with your solution.
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

Code Review Process

Submitters should be pro-active getting their work reviewed
Work-Item Owner (WIO) definitely should review related commits

Submitter should always self-review before submitting to gerrit.onap (use IntelliJ history view or Nodix commit)
Aspects to review
- Functional/AC -> WIO
- Technical/quality. Anyone should be able to
Not all coders need to get involved in all reviews, this could be counter productive
- Ideally about 4 reviewers in total
  - Scenario A
    - Submitter
    - Work Item owner
    - + 2 additional reviewers
  - Scenario B
    - Submitter = Work Item Owner
    - Other Senior developer
    - + 2 additional reviewers
Others can view of course , maybe alert blocking issues. But preferably focus on more relevant commit reviews
See also Committer Best Practices

Code Requirements

Copyright included in each file. Apache 2 for coding files.
1. The Copyright line for contributing organization inserted or updated reflecting the contribution year.
A LICENSE.txt file placed at the root of the repo to provide umbrella coverage.
Unit testing coverage > 90% using Persistence Layer Testing and Groovy & Spock
We will follow ONAP Recommended Software Development Best Practices: Developer Best Practices

Help-process

Preferred the agreed point if Contact as per Plan
- WIO can be found in CPS R11 Release Planning
Agree in Stand-up who can help

JIRA Status Updates

Move To	When
In-progress	The moment you start working on it (incl. analysis)
Submitted	The story/task is ready to be reviewed.
Delivered	The review is merged, merge & CICD jobs are successful.
Closed	Documentations are updated. Complete demo to team.

POM Versioning

Major: Update for major changes
Minor: Update for backwards-incompatible changes
Patch: Update for new functionality, APIs, & REST endpoints

Steps to follow when bumping version:

Update all pom files
1. set to x.y.z-SNAPSHOT by running mvn versions:set -DnewVersion=<snapshot version>
Update major, minor, patch, as needed, in version.properties
Add section in release-notes.rst for next release
Update commit message (if applicable)

Browser not supported