Version 1, last updated on 2023-10-19
Hello, this doc is about explicitly defining quality in the world of services software at Mozilla.
Definition: quality refers to the degree to which a software and its related deliverables meet or exceed the expectations of its stakeholders. However, what are those expectations and does the team share the same expectations? This document defines what the expectations are and provides a way to measure the quality of a software.
Quality guarantees reliability and maintainability of the software, as well as efficiency of development.
The goal of this initiative is to increase the familiarity of codebases, so we can be effective sooner. Ultimately, this means more of our time can be spent on innovation and less on just keeping the lights on.
More projects than people is a common situation for service engineers at Mozilla. As priorities shift, reorgs happen, projects are moved around, at some point we are maintaining several codebases. Most of these projects were not developed to a shared set of quality criteria so there is little familiarity between them.
Note: Instead of enforcing a limited set of rules, we made the choice to have many rules and a global score. Scorecards show complicance in each category, which allows progress in iterations.
A messy workbench © Dan Larson | A professional workbench © mtneer_man |
Objectives:
Non Goals:
For comments and questions, don't hesitate to get in touch in the #coreservices
Slack channel, or open issues and pull-requests in the source repo.
Ergonomics (ûr″gə-nŏm′ĭks): Design factors, as for the workplace, intended to maximize productivity by minimizing operator fatigue and discomfort.
Rule | Description | Details | Popularity |
repo-standard-files |
|
See https://en.wikipedia.org/wiki/Contributing_guidelines and https://mozillascience.github.io/working-open-workshop/contributing/ templates at https://contributing.md | |
repo-standard-folders |
|
||
repo-readme-sections | Readme contains the following:
|
Our goals here are:
|
|
repo-makefile-targets | Make has the following targets:
|
||
repo-main-branch-name | Main branch is called main |
||
repo-main-branch-protected | Main branch is protected without exceptions | ||
repo-version-tags-protected | Tags starting with v* can only be pushed by maintainers/admins |
Github docs | |
repo-issue-labels | Standard issue labels exist:
|
||
repo-team-reviewers-permissions | Team of reviewers has at least “Maintain” permissions | ||
repo-pull-request-merge | Only “squash and merge” and “rebase and merge” are allowed | ||
repo-pre-commit-optional | Pre-commit hooks are optional | Example in Taskcluster |
Rule | Description | Details | Popularity |
repo-release-notes-auto | Release Notes are generated from commits using .github/release.yml |
Sections titles contain at least “Breaking changes”, “Bug fixes”, “New features”, “Documentation”, and “Other changes” | |
repo-dependencies-auto | Pull-requests are automatically opened for dependencies | File .github/dependabot.yml and/or renovate.json exist |
|
repo-automerge-enabled | Automerge and merge queues are enabled | ||
repo-head-branch-auto-delete | Auto-delete head branches is enabled | ||
repo-code-owners | Code owners are configured | At least with team of reviewers for everything (eg. @syseng-reviewers) |
Rule | Description | Details | Popularity |
test-lint-secrets | A test verifies that no secret is committed to the sources | Eg. Yelp/detect-secrets | |
test-lint-code-format | A test verifies that code format respects standard | Eg. prettier, black+isort, cargo fmt | |
test-lint-static-analysis | A test verifies that code respects idioms and good practices | Eg. eslint, bandit+pylint, cargo clippy | |
test-lint-type-checking | A test verifies that types are used consistently | Eg. typescript, mypy | |
test-unit-coverage | Unit tests fail if coverage is under 90% | Better if 100% with branching option | |
test-documentation-build | A test verifies that documentation builds successfully without warnings | If the project does not have built documentation, a lint check for markdown files is recommended | |
test-container-build | A test verifies that container builds successfully | ||
test-container-integration | A test executes integration tests on the built container | ||
test-pull-requests-labels | A test verifies that pull-requests have labels | ||
dependencies-reproducibility | Dependencies are locked between local clone, tests, and container | Eg. use poetry, cargo, … |
These checks apply to services that still rely on tags and releases. If a service has moved to Continuous Delivery, without tagging or releasing at all, they can all be considered as compliant.
Rule | Description | Details | Popularity |
release-semver-calver | Project follows SemVer or Calver version scheme | ||
release-tag-v-prefix | The release tags have v(.+) format |
||
release-tag-only | Project version has a single source of truth. For example, it is read from version.json
which is automatically built from current git tag |
Does not apply to libraries, where a version number usually appears in package metadata | |
release-publish | Project container or package is published on git tag |
Rule | Description | Details | Popularity |
deployment-dockerflow | Container follows Dockerflow spec | ||
deployment-integration-test | Integration tests are part of deployment pipeline | Might be as well end-to-end (browser tests) | |
deployment-auto-main | Automatic deployment on DEV/STAGE environment on pull-requests merge | ||
deployment-auto-release | Automatic deployment on STAGE/PROD environment on version tag | If they pass through a quality gate like an automated integration test | |
deployment-auto-pull-requests | Automatic deployment on temporary instances on pull-requests | Should be allowed to repo owners only? |
Rule | Description | Details | Popularity |
monitoring-heartbeat-backends | Heartbeat endpoint checks that backends can executed desired operations (eg. DB, cache, filesystem etc.) to support troubleshooting | ||
monitoring-heartbeat-error | Heartbeat checks throw errors that will be reported | ||
monitoring-requests-duration | API requests processing duration is monitored | ||
monitoring-requests-id | A unique ID is associated to each request and logged | ||
monitoring-backends-duration | Backends calls durations are monitored | Existing standards | |
monitoring-logging-level | Logging has INFO level by default | ||
monitoring-logging-mozlog | Logging format is MozLog by default | ||
monitoring-logging-env-configuration | Logging level is set using LOG_LEVEL env variable. Logging format is set using LOG_FORMAT env variable |
||
monitoring-error-reporting | Sentry is setup by environment |
Rule | Description | Details | Popularity |
telemetry-metrics | Project sends live telemetry | StatsD with tags | |
telemetry-naming | Probes start with project name (eg. ctms.* ) |
||
telemetry-documented | Probes are listed in documentation | ||
telemetry-query-examples | BigQuery example queries are given in documentation |
Rule | Description | Details | Popularity |
notifications-error-chat | Sentry reports to Slack channel | Sentry creates Github issues? |
Rule | Description | Details | Popularity |
documentation-decisions-records | Enumerate evaluation criteria. | Enumerate considered options with score/comment for each criteria. | |
documentation-security-assessment | Rapid Risk Assessment, either a link or its content | ||
documentation-dev | Instructions for a developper: how to run the tests, procedures to obtain credentials on dev/stage instances, contribute, contact the team, etc. | ||
documentation-test-args | Instructions on how to run test suite with custom arguments (eg. test selection, verbosity, etc.) | ||
documentation-operator | Instructions for an operator: how to deploy and run the application, how to configure it for production, etc. | Can also be called “Deployment docs” | |
documentation-troubleshooting | Common troubleshooting steps |
Missing from standard v1:
Missing from standard v1:
docs/
)
Missing from standard v1:
Missing from standard v1:
Missing from standard v1:
Missing from standard v1:
Missing from standard v1:
Missing from standard v1:
Missing from standard v1:
run
instead of start
and lintfix
instead of format
)
Could not be verified:
Missing from standard v1:
Could not be verified:
Missing from standard v1:
Could not be verified:
Missing from standard v1:
Could not be verified:
Missing from standard v1:
Missing from standard v1:
Missing from standard v1:
Missing from standard v1:
yarn release
)