Coding as a Team

A few guidelines for your day-to-day collaboration within the team

Feature Development Flow

1. When you start working on a story:

• "Start" the story in Pivotal Tracker

• Create a feature branch [feature/name-of-feature]

2. Once you are done developing the 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

3. Once the feature has been reviewed and corrected:

• Merge master in the feature branch

• Squash merge the feature branch in master

• "Deliver" the feature in Pivotal Tracker

4. Once the code is on master:

• 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

Same rules apply when your target branch is a release branch, just replace master by your release branch in the steps above.

Notice that, to ensure easy collaboration within the team, we also try our best to use git according to the best practises. Especially, we do prefer merge over rebase, and never force push when working in collaboration.

Code Reviews

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 asking 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.