Tech team docs

# Workflow

# Intro

This section presents our framework for patching - smaller changes to the code base e.g. bug fixes, handling of various vulnerabilities, minor changes to existing features

# Patch management process

The process centers around:

  1. Identification of patch potential / bugs / fixes
  2. Documentation and tracking of patch fixes
  3. Prioritization of patches
  4. Execution of patch - including reviews and testing
  5. Patch Release

# 1 Identification of patches

Patches are identified via the following sources and all managed in Trello and Jira

  1. Bugs reported from customers - often via Customer Success are added to Trello (bugs are screened by the Tech team and added to Jira if relevant)
  2. Bugs identified by internal employees who use our own software and systems are added to Trello (bugs are screened by the Tech team and added to Jira if relevant)
  3. Exception handling system - Sentry - directly added to Jira after daily screening of the tech team
  4. Vulnerability scanner: Snyk.io and AWS inspector or Dependabot are added directly to Jira
  5. Annual penetration reports - outcomes are added to Jira and prioritized

# 2 Documentation and tracking of patches

Regardless of the source, bugs needs to be added to Jira including as much background information as possible - including the source

For all non-urgent patch requirements, patches are prioritized as part of the bi-weekly sprint planning meetings and managed via tickets in Jira

# 3 Prioritization of patch efforts

By default critical patch requirements always take priority over all other engineering efforts. Non critical patch work is normally planned as part of the bi-weekly sprint planning.

Critical patch requirements are defined as either: 1) a bug or vulnerability that put client data at risk, 2) a bug that negatively impact the experience of more than 5% of the existing users

# 4 Executing patch fixes

If possible, eExecuting patch fixes follow the process:

  1. Recreate the issue
  2. Write a test to recreate the bug / issue via automated code for CI
  3. Update the code to make sure the test pass
  4. If possible: validate the related UX / UI and make sure it all works
  5. Create a PR
  6. Get at least 1 person in the Engineering team to review the change
  7. Ensure all automated tests still pass
  8. Ensure the patch does not have in security implications

# 5 Patch releases

Patch releases are conducted on a ongoing basis and do not include a wider change management process. However, if the patch / bug did expose client data relevant clients must be informed via the Customer Success team.

← Code practices →