Spitfire - Definition of Done v2.0

Owned by Natalia Zaitseva
Last updated: yesterday at 9:22 AM by Valery_Pilko
2 min read

Please note that all items in the checklist marked with [M] are mandatory.



Checklist

Feature/User Story

Sprint Demo/Review

Release

[M]

Unit tests are written and are passed. At least 80% code coverage is expected and 100% is preferred for critical code.

Y



[M]

Pull requests for all Spitfire modules should follow the rules:

  • PR should be assigned to the creator

  • PR title should follow the pattern JIRA-Number + summary
     

    Example

    MSEARCH-497 Anchor query result for subject browse returns >= 1 result

  • PR description should follow the repository pattern or existing template in folio.org and contain a .gif of the feature implemented where it's appropriate
  • PR should stay in "Draft" until all checks passed
  • Peer code review is performed by the Spitfire team(front-end/back-end).

Assign @folio-org/spitfire-backend or @folio-org/spitfire-frontend as reviewers when the build passes successfully and PR is ready 

  • PR should get at least 2 peer approvals
  • PR should be "Squashed and Merged"
  • Remove the branch after merge.

Y



[M]

Peer code review for non-Spitfire modules should include the Dev Lead of the team that owns this module according to Team vs module responsibility matrix.

Dev Lead(or his substitute person in case of absence) approval is required(maybe some exception like for the data-import feature).

Y

[M]

Fix reported code smells, security vulnerabilities, check style issues(by checkstyle maven plugin), lint errors that are reported by Sonarqube and other tools in CI pipeline before merging code to master

Y



[M]

Existing Karate tests (backend modules) and Integration tests (UI modules) are maintained/implemented/improved and pass

Y



[M]

Any configuration and/or build scripts are updated and tested

Y



[M]

Build deployed successfully to the snapshot-stable environment(test, integration etc.)

Y



[M]

QA is performed and issues resolved

- Test-cases are created in "Testrail" against acceptance criteria.
- Story/Feature is tested by QA against acceptance criteria on supported browsers/devices/reference env pass.

Y




Regression tests pass 



Y

[M]Data migration scripts are implemented for schema changesY

[M]

Verify that PII stored is encrypted

Y



[M]

Verify compliance with GDPR – future requirement

Y



[M]

Feature OK’ed by UX and complies with:

- https://ux.folio.org/docs/guidelines/

- WCAG 2.0 Level AA accessibility compliance
- Validate with John Coburn before coming with new design patterns in UX that’s not consistent with Stripes

Y



[M]

Feature is accepted by PO

  • Feature implemented meets acceptance criteria defined by PO/TL
  • Move the story to “in Review” to notify PO about readiness who will review and move it to Done if acceptable

Y



[M]

Localization is taken care of in application code

Y



[M]User documentation updated - README.md, response example files etc.Y

[M]Any bug created, should have a "RCA group" valueY

[M]

No open critical bugs on any user stories


Y


[M]

DoD of each user story, included in demo are met


Y


[M]

All demoable features are demoed from the same shared environment – For most demos, this will be FOLIO integration environment


Y


[M]

Releases are created following: https://dev.folio.org/guidelines/release-procedures/



Y

[M]

Installation and deployment scripts are updated



Y


Actualise performance tests for backend modules and run them before schema upgrade testing during release 

Y
[M]

Performance tests are created and pass – Example: All end-user interactions < 2 seconds for 95 percentile or no degradation in response time for existing functionality



Y

[M]

All bugs reported by QA, manual testing, UAT, PO etc. are fixed



Y

[M]

Release notes are created/updated

Y


Y

[M]

User documentation updated (deployment documentation, scripts/packaging etc.)



Y

[M]

User documentation is localized



Y