[Draft] Baseline DoD
- Denis
DRAFT
Intent
We continuously aspire to enhance the quality of the product. As many teams contribute to the product development, we support every of them by providing a baseline DoD for user story/bug which aims to help meeting target level of quality for smallest delivered value.
The Baseline DoD will be reviewed every release and in case further improvements are suggested/introduced, it will be updated accordingly and communicated to the teams.
Important to note, that on top of the Baseline DoD any team is welcome to add more specific activities that correspond to team's working agreements to reflect team's specific area of work, way of collaboration, etc.
Baseline DoD (User story/Bug)
| # | Activity | Responsible | Comment |
|---|---|---|---|
| 1 | Implementation of the requirements is completed AND acceptance criteria of the issue have been met | Dev | |
| 2 | Any bug created, should have an "RCA group" value | Dev/PO | |
| 3 | Any PII data stored is encrypted (if applicable) | Dev | |
| 4 | Data migration scripts are implemented for schema changes (if applicable). | Dev | |
| 5 | Sample and reference data is updated to match the feature or schema change (where applicable) | Dev | |
| 6 | Unit tests are written and passing (at least of 80% code coverage is expected for new code and 100% is preferred for critical code) | Dev | |
| 7 | API Karate tests are written/updated and executed (passing if applicable) | Dev | |
| 8 | Translation keys are included in application code (code doesn’t rely on hardcoded values) | Dev | |
| 9 | Functionality is checked with non-admin user (appropriate permissions are set for regular user to make sure that verified functionality is accessible) | Dev/QA | |
| 10 | Dev verification is performed by a developer on Vagrant Box/Rancher/Snapshot/Bugfest environment and issues resolved if found | Dev | |
| 11 | Backend functionality is checked on multi-tenant environment (Performance, Sprint testing, Bugfest) with the help of Karate tests where possible | Dev | |
| 12 | Reasonable code smells, security vulnerabilities, lint errors that are reported by Sonarqube and other tools in CI pipeline are fixed before merging code to master (comment is left in PR in case issues are not fixed)) | Dev | |
| 13 | Pull request is approved by at least one other developer. In case repository belongs to another team, at least one approval from the owning team is required. | Dev | |
| 14 | Code is available on folio-snapshot.dev.folio.org or folio-snapshot-2.dev.folio.org for current release or specific environment in case of hotfixes/bugfixes | Dev | |
| 15 | Accessibility check list is considered, and new functionality covered with accessibility tests | Dev | |
| 16 | Interface version (for backend modules) and module implementation version (for backend (pom.xml) and UI (package.json)) is updated according to the versioning procedure: https://dev.folio.org/guidelines/contributing/#version-numbers. The fixVersion field in JIRA (user story) is updated to match the version that ships the feature/bugfix | Dev | |
| 17 | A note in dev channel on API major version changes is posted (if applicable) | Dev | |
| 18 | Module descriptor includes actual information regarding required resources for particular module and readme file and deployment information is updated | Dev | |
| 19 | QA verification is performed by a QA/developer on multi-tenant environment and issues are resolved if found | QA/Dev | |
| 20 | The work delivered is tested and accepted by PO (or another stakeholder if applicable) | PO/Dev |
Baseline DoD review Process
