-
Notifications
You must be signed in to change notification settings - Fork 0
For Developers: Development Workflow
This is a proposal.
We use Github projects to manage our development workflow. The board has the following columns, order from left to right:
- Backlog - where tickets initially go
- Next Sprint - Issues queued up to be worked on in the next sprint
- Current Sprint - Issues to work on this sprint
- In Progress - the assigned developer is actively working on the ticket in the current sprint
- Closed - all ticket's associated PRs have been merged to
main. These have been deployed to QA and are ready for review - Complete - the ticket's associated commits are in production and deployed
Once a ticket is in "Complete" it can be archived. At that point, it's removed from the board, but the issue is still in Github. The ticket can be re-added to project if needed, and it would go back to the "Backlog" column.
Hotfixes should be branched off of main so they can be merged into main and released once their PRs are completed.
As issues get added to the repository, they can be added to the project kanban board. Every ticket doesn't have to be in the project, only the ones that we know we'll want to work on. Milestones are used independently of the project board as a means of grouping larger features.
Issues that require more than one "subticket" to complete are denoted with an "Epic" label. As the separate subtickets are added to the epic ticket, Github will created a "todo" list and track each one as it's closed.
Epic issues get added to the kanban board just like any other ticket, but it usually stays "In Progress" until all the subtickets are closed and at that point can be closed itself, and moved through the rest of the workflow.
Typically, each issue will have one PR associated with it. The PR should have a linking word in it that links to its related issue. See Linking a Pull Request to an Issue PRs can still be linked to an issue without using these words, it just has to be done manually in the edit page of the PR.
Issues can have multiple PRs, if needed.
PRs are not tracked automatically in the kanban board because they're most often linked to an issue. However, PRs can be manually added to the board and moved through the workflow if needed. Although it may be preferable to write up a ticket that documents the requirements for the change instead of trying to use the PR to do that. Note: this is up for debate
Another member of the team needs to approve a PR before it's merged. Ideally it should be someone who wasn't directly involved with writing it. The requirements for an acceptable PR should be as broad as possible, but the PR should pass any required checks such as CI testing, code coverage, and linting. The determining factor for the reviewer is simply: Do I understand this?
Note: This is up for discussion!
Complex issues often need multiple commits and multiple commits may arise from a single issue through the review process. When a PR is merged with multiple commits, we have the choice of keeping those commits or not. Keeping the commits creates a merge commit in the destination branch, and not keeping them squashes all the commits up into one commit that's added to the destination branch.
If the commits are designed to separate refactoring from the issue fix, or to otherwise separate other logical bits of work that are peripheral to the issue fix, then keeping those commits separate when it's merged is probably a good idea. This is at the description of whoever is merging the PR. The PR author can also ask for the commits to be kept if they aren't going to be merging.
Lengthy reviews processes and corrections for typos and/or linter errors can create lots of commits that aren't significant. It's a good idea to squash those when merging. Even after the PR is squashed and merged, the original commits will still appear in the PR, along with any relevant comments, even though the actual commits won't be in the repo.
Instead of pushing a new commit each time, the dev can elect to squash changes into the existing commit and force push those up to the repo. This is handy if you want to retain multiple organized commits but need to fix spelling or linter errors.
Check out deployment procedures here: https://github.com/psu-libraries/researcher-metadata/wiki/For-Developers:-Deployment-Procedures