"Start" the story in Pivotal Tracker
Create a feature branche [feature/name-of-feature]
Create a pull request in GitHub
"Finish" the story in Pivotal Tracker
Ensure the review app is properly configured and working
Do a functional test on the review app
Ask for a code review (in GitHub) & a functional review in Pivotal Tracker
Merge master in the feature branch
Squash merge the feature branch in master
"Deliver" the feature in Pivotal Tracker
If the build and deploy to staging goes fine:
Promote to production
"Accept" the story in Pivotal Tracker
If the build and deploy to staging goes bad:
Revert the commit
“Reject” in Pivotal Tracker
We do systematic code reviews - each feature or fix, as small as it can be, needs to be reviewed by another team member before going to staging then production.
A code review is first and foremost a discussion about how to make the code better.
In order to make this fast, issues available for review should be given priority over new issues to work on. We want to get them out as soon as possible.
As a rule of thumb, look at the review column when you arrive in the morning or after lunch and pick up what you can before going back to your own work.
As the committer, try to make the work of your reviewer easier:
Include a screenshot of the feature
Put any information required to test/reproduce
Do yourself a review before as king others:
Run linters or check CodeClimate report
Ask yourself what you would comment on that code
Our general approach is the boyscout rule: leave the code in a better state that you found it.