Development

Git Strategy

All repos should follow the same git strategy. Each feature gets a feature branch. When starting to develop a feature, create a Merge Request (MR) and prepend the WIP status to it. When the MR is complete, remove the WIP status and assign approvers. Each MR needs approval from the Code Reviewers team and the QA team, who will offer feedback. When the MR is approved, it is the assignee’s responsibility to merge to master.

The master branch represents a rolling release candidate and runs against the production database. It is then up to the Product Manager and CTO to tag the release, which in turn initiates a production deployment. It is very much our strategy to “release early, release often”, we will often initiate multiple production deployments in one day, as and when features merge to master.

Code Review

Code reviews serve two purposes: educate developers and keeping code smells from entering the project. Having your hard work picked apart by your peers can be a

Some thoughts to consider:

• The point of a code review is not perfection, if the MR improves the state of the codebase, it should be approved.
• Style is largely handled by linting.
• Over-abstraction is as bad as under.
• Clarity is to be preferred over brevity and flourishes.
• Naming things properly is important.*
• People have worked hard on code you're reviewing.
• There are often multiple good ways to do things, just because it's not the way you would have solved the problem, doesn't mean it's wrong.
• Code review has the same priority as coding itself.

Remember, it is easier to write code than read code. Code reviews are hard, take them seriously.

Quality Assurance

Each new feature is QA tested before release. Each developer should include a test script in their merge requests.

Automated Testing

E2E tests on representative data are as vital, if not more so than a litany of unit tests.

* there are 11 hard things about programming: cache invalidation, naming things, binary and off-by-one errors.