Checkbox Code Checkin Process
Checkbox uses a standard checkin process to help ensure quality and minimize back-tracking later in the release process. The order is as follows:
- When beginning work on a checkin, a new branch should be created. When creating a fix for a defect, the name should be "/fix/checkinNameHere". For features, it should be "/feature/checkinNameHere". For major projects, there may be a different root name, but most should fall into this naming scheme.
- Code changes should be scoped to the minimum needed changes. Refactors can be included if they do not result in a large checkin, but remember that large checkins are a pain to review and therefore will naturally wait longer for a review.
- The initial pull request should be made to merge into develop.
- When creating a pull request, the Asana task related to the checkin should be noted in the PR comment. Further comments are not required (the Asana task should describe what's being done and why), but may be helpful if complex technical decisions were made.
- After creating the pull request, the Asana task should have a comment added with a link to the PR.
- All non-trivial, non-emergency PRs should be approved by at least one reviewer before merging. All developers should set aside time each day to review PRs.
- A significant commit should be approved by the VP of Engineering, either as the one approval or in addition to it. "Significant" means that it is a new feature or highly visible fix.
- After the needed approvals, the PR may be merged into develop and the release process can be followed further: merge to staging, verify in staging, wait for a release date, release.
One or more steps in this process may be skipped at the discretion of the VP of Engineering, especially in the event of needing to quick-fix the Checkbox Online SaaS platform. We should try to minimize these events.