When you start working on a new story these are the steps that you need to follow:
- Start a new local branch from the appropriate branch
- Work on completing the work that the story requires
- Try to commit often and include logical blocks of work. Makes it easier to revert
- Keep commit messages short and descriptive
- If you are unsure about the way you are solving the task at hand, pair with another developer to get their opinion
- If you ticket requires the same change in many places, try to apply it once, ask for an early review before replicating the work everywhere
- Keep an eye out for other stories/PRs that are being worked on and follow the ones that work on the same part of the code as you are. Think ahead of how the two are going to be merged together and if needed, discuss with that developer on a strategy to do so
- PR early even when you are developing, and mark the PR as WIP. It might be useful for others to take a look at the work early
- Push up everything you have at the end of each work day
- Make sure all checks pass before asking for a review
- Once your PR is marked for review, try to mention it in a channel so others can see
- In order for the PR to move to the next step (QA) you need at least one approving review from a senior developer on the team
- For this project either @karaggeorge or @maggiemccain
- When changes are requested, follow these steps:
- If the comment is positive or just noting that something was implemented in a good way, you can resolve it
- In any other case, you should not be the one marking it as resolved
- If you think the comment makes sense and you know what to do, make the change
- If you need more info or think the request was made in error, reply to the comment with a concise explanation
- When you are done making the changes re-request a review from that person
- The comments will either be resolved from the reviewer or by your code changes
- The only time that you can decide not to make a change is if the change requested is out of scope from the original story, in which case you can request a new story to be created
- Keep in mind that feedback is meant to be constructive
- Passing code review is as big a step as passing QA or UAT. It's required for a story to move on to the next step
- It prevents bugs from every reaching the codebase
- Promotes good code standards
- More eyes are always better
- Prevents technical debt from being accumulated in the codebase
- Allows transfer of knowledge
Code reviewing is a skill of its own. It's super important and it's a great skill to have. Like any other you learn by doing it. When you finish a story and have a couple in review, sometimes it's better to wait for those to get in before starting something new. During that downtime, try to look through the PRs for some that require review. Try going through the code changes to see if you can find something that the author missed. At first look for small typos, unecessary statements that were left in the code, or left over console.logs. Later on you can start looking at the bigger picture and start making suggestions on the architecture of the story or the strategy that was taken to solve the task. The more you do it, the better you'll get.
After the story has passed code review, share a link with the QA team and ask them to test it. If they find any issues that need code changes iterate with them until they're fixed. After that, if any code changed in the process, you need to ask for another code review on those changes. When that is complete as well, the story can be marked as ready to be merged.
Before merging a story, make sure it's up to date with the target branch (master in this case). If you try to merge master and get a lot of conflicts, especially if you're unsure what story they came from, don't try to resolve them on your own. Ping the developer that worked on the story which created the conflicts and go through the changes together to make sure nothing gets left out. A bad merge is one of the harderst things to fix once it's been pushed to the target branch.
If the merge had a lot of conflicts, it might be worth asking for another small QA session to make sure nothing broke in the process.
When the story is merged, you can assign it to UAT in the story board and move on to the next task.