# QAing and deploying code
Reviewing code is a task that is generally handled by both the developer themselves and a reviewer(s). Broadly speaking the developer will take things as far as they can on their own with the goal of minimizing the reviewers time and energy. On the flip side, the reviewer(s) will provide a second set of eyes to validate acceptance tests and code quality.
The specific action items assigned to a developer and reviewer can differ from project to project and are generally enumerated in a given project's pull request template. For example, here is the template for this repo. You can read more about how that works above.
That said here are the two general flows you'd take depending on your role.
# Developer Flow
# 1. Housekeeping
On a high level this means making sure the PR is as ready to go as possible. It could include making sure your code has pulled in the latest from
master, that any relevant doc changes have been reflected or that you've written an acceptance test.
If a reviewer has to remind a developer they've missed basic things on their checklist it vastly impacts team flow.
# 2. Automated Tests
The developer is also responsible for making sure all automated status checks contained in the PR have passed before they request a review. Generally, these tests will handle things like:
- Code linting and code standards enforcement
- Unit and functional tests
- Code analysis and review
# Reviewer Flow
# 1. Acceptance Tests
Each pull request will automatically spin up a separate QA environment on Platform.sh. This enables a manual acceptance testing flow by stepping through a user journey on the QA environment and verifying it does what it is supposed to do.
It also allows us to compare user journeys between the QA environment and some control environment (usually dev or production) to test bug fixes.
Every pull request template will generally have an example acceptance test for the developer to flesh out. This means that the reviewer is not responsible for writing this test, only verifying it does what it says it does.
# 2. Code Review
The final responsibility of the reviewer is to ensure the code is good enough to be merged. Generally, this means
- Looking out for any low hanging logic errors or cheap improvements
- Ensuring the code fits into the projects architectural plan
- Ensuring the code is not defining a new way to do something we already have a pattern for
- Reviewing relevant code analysis feedback eg a Code Climate Report
If you are unfamiliar with GitHub's pull request review system then check out these docs.
# 3. Client review
@TODO: Dustin and MM?
# 4. Deploying Code
Once the PR template checklist is complete and both the client and reviewer are feeling good about things you may press the button