Add performance guideline of GitLab.com scale to definition of done
What does this MR do?
To continue making GitLab.com enterprise-grade (FY21 kickoff slide 44), we should modify the existing contribution guideline definition of done to require MRs to meet the scale and performance needs of GitLab.com.
Performance guidelines
We currently have a Performance Guides section in the Contributor and Development Docs:
- Instrumentation for Ruby code running in production environments
- Performance guidelines for writing code, benchmarks, and certain patterns to avoid
- Merge request performance guidelines for ensuring merge requests do not negatively impact GitLab performance
- Profiling a URL, measuring performance using Sherlock, or tracking down N+1 queries using Bullet
We should update these docs to define what Gitlab.com scale means and provide a way for contributors to understand whether they've met this requirement or not. This might be something we can build into GitLab GDK?
There are also multiple ways we can define GitLab.com scale. A starting point can be to look at the number of rows our database currently has.
Does this conflict with iteration? Will this result in premature optimization?
This change should not contradict our focus on iteration. We should focus on iterating feature scope while maintaining a baseline level of Gitlab.com performance. Every iteration we release should be a functional on GitLab.com even though it might not have all the bells and whistles.
Here's an example of iteration we discussed during the 2020-01-30 EVPE office hours
Skateboard is not as fast as a car, but it’s fully functional (i.e. works at GitLab.com scale)
Next steps
- Gather feedback. What does everyone think?
- Update the performance guidelines to define GitLab.com scale
- Provide a way for contributors to understand whether their changes meet the GitLab.com scale requirements.
cc: @edjdev @ayufan @rmarshall
Related issues: