Eureka Definition of Done

Owned by Oleksii Kuzminov
Last updated: Oct 11, 2024 by Dima Tkachenko
4 min read

The Definition of Done (DoD) is a shared agreement within the development team that outlines the criteria a user story or task must meet to be considered complete. Adhering to this ensures consistent quality, facilitates smooth collaboration, and maintains the integrity of our software products.

1. Code Quality

1_j_OxwFNBFGlKtdRLqUGepg.jpg

  • Code Coverage

    • New code must have a coverage of 80% or greater unless explicitly noted otherwise in the story's acceptance criteria.

  • Static Code Analysis

    • All reported code smells, security vulnerabilities, and lint errors identified by SonarCloud and other CI pipeline tools must be fixed before merging code to the master branch.

    • There should be no bugs or security issues should be reported by SonarCloud upon merging.

  • Code uniformity

2. Pull Requests (PRs)

  • PR Descriptions

    • Every PR should include a detailed description with:

      • Purpose: The intent and objectives of the changes and a link to the User Story (if available).

      • Approach: The methodology and reasoning behind the implementation.

      • Open Issues: Any unresolved questions or potential problems.

  • Approval Requirements

    • A minimum of two developers must approve each PR.

    • At least one approver must be a team lead or architect.

3. Testing

Screenshot_1.jpg

  • Unit Tests

    • All new functionality must be covered by unit tests to meet the required code coverage.

  • Integration Tests

    • Integration tests should be created if applicable.

  • Performance Tests

    • Performance tests should be developed if relevant to the changes.

  • Testing Environments

    • For developer testing, use the Kitfox Dev Rancher Environment.

    • For QA testing, use the Kitfox Testing Rancher Environment.

4. Documentation

  • User Documentation

    • Update all relevant user and deployment documentation, including scripts and packaging instructions.

  • Configuration and Build Scripts

    • All configuration files, Docker files, and build scripts must be updated and tested to reflect changes.

  • Personal Data Disclosure

    • The personal data disclosure form must be updated as needed to comply with data handling policies.

5. User Story Workflow

  • Jira Workflow Columns

    • Todo

    • Blocked/Questionable

    • In Progress

    • In Code Review

    • In Deployment

    • In QA

    • In PO Review

    • Done

  • Status Transitions

    • Blocked/Questionable: Move the story here if some impediments or uncertainties need resolution.

    • In Progress: Move the story to In Progress when development begins. During the development process, a developer should move the story to the most relevant project in JIRA. There shouldn't be any stories in the EUREKA project that have PRs. If there is a need to make the code changes in multiple projects - create a story per project and link them to the main bug or story.

    • In Code Review: Move the story to In Code Review after development is complete and a PR is ready. If it is a bug, a developer should fulfill the RCA field.

    • In Deployment: After deploying the code to the Kitfox Dev Rancher Environment for developer testing and validation, move the story to “In Deployment” and merge the PR to the master branch. Before the merge, all comments in pull requests should be marked as resolved.

    • In QA: After deployment to the Kitfox Testing Environment, and when the QA team begins testing, move the story to In QA.

    • In PO Review: Once QA has verified the story and it's ready for Product Owner (PO) review, move the story to In PO Review.

    • Done: Move the story to Done after the PO has accepted the story and no critical issues are remaining.

  • Acceptance Criteria

    • All acceptance criteria outlined in the user story must be fully met.

  • Critical Bugs

    • Ensure there are no open critical bugs associated with the user story before moving it to Done.

6. Demos

  • Demo Environment

    • All features eligible for demonstration should be demoed from the shared Kitfox Testing Environment.

  • Team Presentation

    • The story must be presented to the team during a demo session (if applicable).

    • The Product Owner (PO) moves the story to Done if there are no critical issues.

7. Spikes / Proof of Concepts (PoCs)

  • Documentation

    • Document all spike findings on the wiki and present them to the team.

    • Place PoC findings in the team's space on Confluence.

  • Code Accessibility

    • Check PoC code into GitHub to make it accessible to the entire team.

  • Follow-up Actions

    • Create user stories to implement or formalize the preferred approach or solution (if applicable).

    • Share the resulting Jira issues with the PO for awareness so they can ensure the issue metadata (labels, features, etc.) is accurate and complete.

  • Acceptance and Recording

    • The PO and the architects' team are responsible for accepting after spike findings are presented and discussed.