Hi Blaine, great stuff - thanks for sharing! I've got a question about "releasing" a pull request for review. How do you handle this, practically speaking, in Bitbucket? Does your team create pull requests, then conduct self review, then add reviewers? Or does self review happen before you create the PR in Bitbucket?
Does a successful code review result in a PR "approval", or your processes for review and approval largely separate?
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
create a story in Jira (add an estimate, description, assign to a programmer, etc.)
programmer moves the story from 'to do' to 'in progress' in Jira and then creates a feature branch for the story
programmer makes code changes to satisfy the story (along with a testing plan document, unit tests, etc.)
programmer does a self-review, runs the unit tests, and executes the manual testing plan. Programmer works on the branch until he/she is satisfied that it meets all requirements (or moves it to 'feedback' in Jira to ask for help)
once the programmer feels the branch is ready for review he/she creates a pull request in bitbucket and adds a reviewer. The programmer reviews the diff in bitbucket. I don't know why it's different to look at the diff in bitbucket vs our IDE but we usefully find something to fix while looking at the bitbucket diff (often documentation but it's still important to us).
Now that the branch has been self-reviewed, and reviewed by the programmer in bitbucket, they move the story to 'review' in Jira (this is the "release for review" step you were asking about)
The reviewer knows to review the pull request because they are the assigned reviewer on a pull request for a story in the 'review' column of the active sprint board.
A successful review does result in a PR "approval". But we take it a step further. A reviewer who approves a pull request does the following:
approve the pull request in bitbucket
fill out our code review Google form
merge the branch into master
deploy the branch into production
move the story to the 'done' column in Jira
We think the immediate merge and deploy steps are important for two reasons. First, it signals to the programmer his/her code better be "done-done" when they put it into review because that is their last chance to change it before it goes into production. And secondly, it gets the code into production as soon as possible so it can start delivering value to our stakeholders.
Does that answer your questions? How does your team do it?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Blaine, great stuff - thanks for sharing! I've got a question about "releasing" a pull request for review. How do you handle this, practically speaking, in Bitbucket? Does your team create pull requests, then conduct self review, then add reviewers? Or does self review happen before you create the PR in Bitbucket?
Does a successful code review result in a PR "approval", or your processes for review and approval largely separate?
Hi Christian. Thanks for reading.
We usually do it like this:
A successful review does result in a PR "approval". But we take it a step further. A reviewer who approves a pull request does the following:
We think the immediate merge and deploy steps are important for two reasons. First, it signals to the programmer his/her code better be "done-done" when they put it into review because that is their last chance to change it before it goes into production. And secondly, it gets the code into production as soon as possible so it can start delivering value to our stakeholders.
Does that answer your questions? How does your team do it?