> For the complete documentation index, see [llms.txt](https://docs.podkrepi.bg/development/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podkrepi.bg/development/dev-guidelines/definition-of-done.md).

# Definition of done

We use the definition of done to asses whether or not an enhancement can be considered to be complete (shippable to production). 

### Do not mix DoD with acceptance criteria.

DoD is our general framework to derive and end-to-end process which ensures every common piece of work meets the organisation's quality standards. Whereas, AC is a set of strictly defined targets for each individual (functional) piece of work that must be met before a task is considered to be complete.

### Why is DoD important to us?

It is vital that every contributor in our organisation is aware of and understands our DoD. This helps us:

* Complete all tasks without introducing any gaps in the process.
* Follow with clarity where we are on our roadmap and what has been completed.
* Know what is expected from every contributor.
* Meet a certain quality of our work which leads to:
  * Lowering the amount of time spend for reworks.
  * Delivering on our promise to create a platform which makes a difference in our society.

### Framework

The following is a general approach towards DoD, each team is encouraged to derive their own process suitable for the team's functionality in the organisation.

#### Development

1. Code and unit tests for functionality completed.
2. Assumption of meeting Acceptance Criteria.
3. Premerge \[if applicable] tests and code reviews passed.
4. Postmerge \[if applicable] tests passed.
5. Project builds with no failures.
6. Project deployed to dev environment.
7. Initial QA performed by the developer. \[if this step fails, go back to step 1]
8. Feature documentation \[if applicable] and tests documentation \[if applicable] written.
9. Feature QA'ed by a QA engineer against the acceptance criteria. \[if this step fails, go back to step 1]
10. Official documentation updated.
11. Feature marked as completed.

#### Release

1. All features included in the release are marked as completed. Where a feature is not yet completed, the feature is postponed for the next release.
2. Update changelog and release documentation where applicable.
3. Current environment is "green" - all unit, functional, integration, E2E and other possible tests are passing.
4. Release acceptance criteria is met. \[If this step fails, go back to step 1]
5. QA functionality of the platform. \[If this step fails, go back to step 1]
6. QA if any experimental features are exposed to the end user. \[If this step fails, go back to step 1]
7. Promote the release to the next environment in the pipeline.
8. Release successfully deployed to new environment. \[If this step fails, go back to step 1]
9. Release marked as completed.