This page covers the regular cases may occur developing JIRA tickets. This is not a full-scale development guide, just describes usual states and actions through which JIRA ticket should pass.
|User story (development work)||Tech design (design work)||Spike (research work)|
|Before starting the development|
Make sure your ticket:
|Development ||On this stage main development is considered to be done and we will prepare the changes for code review|
|Code review||On this stage changes are prepared for review, but not shared and not reviewed|
Present your results and findings to the PO (5 mins max):
On this stage changes are shown to the PO
|Final round||Demo your story to the FOLIO community on the general demo event, that usually happens once a month.|
- Does this PR meet or exceed the expected quality standards?
- Code coverage on new code is 80% or greater
- Duplications on new code is 3% or less
- There are no major code smells or security issues
- NEWS.md is up-to-date
- Changes are tested on local machine
- Does this introduce breaking changes?
- [ ] Were any API paths or methods changed, added or removed?
- [ ] Were there any schema changes?
- [ ] Did any of the interface versions change?
- [ ] Were permissions changed, added, or removed?
- [ ] Are there new interface dependencies?
- [ ] There are no breaking changes in this PR.
If there are breaking changes, please **STOP** and consider the following:
- What other modules will these changes impact?
- Do JIRAs exist to update the impacted modules?
- [ ] If not, please create them
- [ ] Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
- [ ] Do they have all they appropriate links to blocked/related issues?
- Are the JIRAs under active development?
- [ ] If not, contact the project's PO and make sure they're aware of the urgency.
- Do PRs exist for these changes?
- [ ] If so, have they been approved?
Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.
While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.