CPS Team Way-of-Working
- Jira Stories/Task are groomed by team in weekly meeting or on demand as required
- 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
- Grooming is not compulsory for Jira (sub)tasks (not affecting source code)
- Backlog should be in priority order.
- Check bugs first, unless specially agreed they always have the highest priority
- Check the next available user story is 'Groomed' and there are no blocking dependencies
- 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
- Check with PTL if story can be taken as there could always be last minute updates or changes that might prioritize a different task
- Inform team about you intention to take user story
- Assign user story to yourself
- Set user story to In progress! (even if starting with some study first)
- If required (typically agreed during grooming) create a Implementation Proposal page here: Implementation Proposals
- 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
- 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
- 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
- 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
- It is always good to give the team a heads up and share early!
- Ensure all team developers are added as reviewer, see Team Members
- The WiP flag in Gerrit can be used to indicate that review is not ready for review with a fine toothcomb yet
- 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!
- Use Code Review Checklist : CPS Code Review Check List
- Please review completely ie. it shouldn't be necessary to add more comments on unchanged code after committer as applied your previous comments.
- 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
- 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
- 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
- Scenario A
- Coder
- Work Item owner
- + 2 additional reviewers
- Scenario B
- Coder = Work Item Owner
- Other Senior developer
- + 2 additional reviewers
- Scenario A
- Ideally
- Others can view of course , maybe alert blocking issues. But preferably focus on more relvant commit reviews
- See also Committer Best Practices
Code Requirements
- Copyright included in each file. Apache 2 for coding files.
- 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
- 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. |