Commit d8bfd42a authored by Marcel Amirault's avatar Marcel Amirault

Merge branch 'dod-changes' into 'master'

Include static analysis tests in Definition of Done criteria

See merge request gitlab-org/gitlab!71686
parents 4463591b 1150940c
......@@ -83,6 +83,24 @@ request is as follows:
migrations on a fresh database before the MR is reviewed. If the review leads
to large changes in the MR, execute the migrations again once the review is complete.
1. Write tests for more complex migrations.
1. If your merge request adds new validations to existing models, to make sure the
data processing is backwards compatible:
- Ask in the [`#database`](https://gitlab.slack.com/archives/CNZ8E900G) Slack channel
for assistance to execute the database query that checks the existing rows to
ensure existing rows aren't impacted by the change.
- Add the necessary validation with a feature flag to be gradually rolled out
following [the rollout steps](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#rollout).
If this merge request is urgent, the code owners should make the final call on
whether reviewing existing rows should be included as an immediate follow-up task
to the merge request.
NOTE:
There isn't a way to know anything about our customers' data on their
[self-managed instances](../../subscriptions/self_managed/index.md), so keep
that in mind for any data implications with your merge request.
1. Merge requests **must** adhere to the [merge request performance guidelines](../merge_request_performance_guidelines.md).
1. For tests that use Capybara, read
[how to write reliable, asynchronous integration tests](https://thoughtbot.com/blog/write-reliable-asynchronous-integration-tests-with-capybara).
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment