Development Processes

Git

  • We follow a gitflow like strategy. All changes are made in branches based off main and once feature complete merged to main as the primary release branch.
  • Merges to the main branch are automatically deployed to development and staging environments respectively using release pipelines in Azure DevOps.
  • Merges to the main branch need to be manually released to development, staging and production environments by a developer.
  • Branches are merged into main via Pull Request (PR)

Commit Messages

  • Use the imperative, present tense: “change” not “changed” nor “changes”
  • No capitals and no fullstops (.) at the end
  • When a PR is ready for merge we trigger a squash and merge which will squash all your commits into one, when doing that follow the pattern of type/scope/ticket-number: description (#PR-number). i.e. style/onboarding/PROJECT-123: change button color to red (#321).

Pull Requests

  • Unit & e2e tests and snapshot updates should be performed prior to pushing your branch to the repository. This limits the the number of unnecessary CI runs and is a time and cost saving measure. More commits, fewer pushes.
  • PR title must follow the pattern of type/scope/ticket-number: description. i.e. style/onboarding/PROJECT-123: change button color to red. scope is optional depending on the work item.
  • Include all relevant labels on the PR (e.g. bug, enhancement, feature, documentation, test, release etc.)
  • Use the following branch-naming format type/scope/ticket-number/description, eg. fix/buttons/PROJECT-124/broken-button, where types are as follows:
    • feat: A new feature
    • fix: A bug fix
    • refactor: A code change that neither fixes a bug nor adds a feature
    • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
    • test: Adding missing tests or correcting existing tests
  • When relevant, add screenshots/recordings to the pull-request
  • You are responsible for getting your code into production, ask for review and follow through
  • PRs require at least 2 reviews, with at least 1 of them being a senior engineer
  • Test your code in production, don’t fire and forget
  • When reviewing, do so thoroughly and actually test the changes
  • PR feedback is criticizing the code, not the author. Don’t take feedback personally, and don’t hold back. Just be polite
  • Keep PR size down. The scope should be to change one thing, we are targeting a 4 hour dev cycle, with as little code change as possible
  • When merging PRs, the commits are squashed and the branches are deleted automatically
  • We use the angular standard for our defined types

Coding standards

Deployment Guide

  • Production and staging branches are always deployed using CI
  • We use Azure pipelines as the preferred build and deployment mechanism
  • Where possible and feasible, we use Infrastructure-As-Code (IAC) for infrastructure definition and deployment

Definition of Ready

  • There is a clear and understandable title and description of the work to be done
  • All dependencies are met, ie. API documentation, API keys, assets, reference links, etc.
  • We have credentials for third-party services if necessary
  • There are clear and understandable acceptance criteria
  • There are valid designs if necessary
  • All of the above (with the exception of secure credentials) are on the ticket

Definition of Done

  • All code is merged all the way into main
  • All changes are deployed to staging and/or production
  • Unit tests pass
  • End-to-end tests pass
  • Changes have been tested in production
  • Acceptance criteria have been satisfied
  • Quality Assurance (QA) and Client are satisfied with the changes
  • N.B. Documentation has been updated