Dev Workflow

Overview

This is a living document describing how we collaborate on the codebase to move work from tickets to production.

Board interaction

• All work must be tracked via a ticket on the board. If a bug is discovered, it should be added there before working on a fix
• Before starting a task, assign the ticket to yourself and move it to 'in progress'
• When the PR is ready for review, move the ticket to 'in review' and link the PR in the ticket

Git/Github workflow

We follow what's officially called github flow with some adjustments. See chingu's version in their handbook

development

• create feature branches from dev. follow <type>/<name> as a naming convention. Use angular's conventional types as inspiration
  • Example: feat/user-login, fix/button-overlap, chore/update-deps
• commit frequently. aim to author atomic commits. name them according to conventional commits. Use Angular conventional types as inspiration
• regularly pull dev for updates, at least once a day, and before you push to create a PR
• any time dev pulls updates, rebase your branch over it, resolving any conflicts (git rebase dev from your feature branch to start the process)

PR creation & review

• as an author:
  • ensure the branch is rebased on top of an up to date dev
  • ensure the acceptance criteria & technical parts in DoD are validated
  • use the PR template as a guide for the description
  • link to the corresponding jira ticket
  • if you want specific feedback, include it explicitly
  • merge your PR if approved, otherwise address all changes before requesting re-review
• as a reviewer:
  • verify CI checks are passing
  • verify the acceptance criteria & technical parts in DoD are validated
  • use your own judgement to give further feedback

Promoting to production

This step will be done collectively as part of our sprint review, in the form of a PR from dev to main, following the requirement in our DoD of POs validating the work