-
Notifications
You must be signed in to change notification settings - Fork 0
Development Process and Testing
Filing bugs: All bugs should be filed under their own separate issues. We have finally reached a point where our app is stable enough to have separate issues for each bug, which will allow us to track our workflow more efficiently. Furthermore, it prevents the organizational issues we've dealt with in the past in regards to filing workflow (Become Guru) issues with their laundry list of bugs (no formal record of bugs to fix as items continually get added or removed, some bug fixes don't get passed into the actual pull request because they were made after the merge and weren't communicated effectively due to having a "master issues' issue, etc).
Fixing bugs: Once a bug has been fixed, the dev will submit a comment on the related issue which will include 1. name of person responsible for verifying bug has been fixed and 2. the link to the pushed branch (after running ug check, see below) that fixes said bug.
Name-Dev Pushes and Pull Requests (ug check): A quick preemptive test (command: ug check) should be run on a dev's name-dev branch before he or she pushes it to the repo, or whenever a pull request is to be made. This test will basically check whether the app is able to compile and run without any errors (ex. reach the access page). This is to prevent the time that is lost after resolving merge conflicts and the app is unable to run on the other dev's environment.
Closing issues: For the most part, issues should not be closed manually. Instead, as bugs are fixed and verified, a pull request will be made by Jason which will include the appropriate tags that Github will parse and automatically close the respective issues upon an approved pull request. Delegating the responsibility of closing issues to Github will ensure that no bug fixes get left behind and that the Staging, and eventually Master, branch will have all the verified fixes or features. In the event an issue is manually closed, the respective team member should add a quick comment about the reason for closing.
Branches: It is up to each dev as to how he/she wants to create new branches or not when fixing bugs or adding new features. However at the very least, there should be a Name-Dev branch that the dev will use when making pull requests.
Pushing to Master (Production): The Master branch should only pull from Staging, which will only contain commits that follow all of the above best practices. And even then as a final check, Jason will run complete E2E tests before the branch is merged.
