TODO:

Development

After a developer is assigned a Jira task, they begin work.

  1. Unless you’re the person most familiar with the area of the codebase that you are changing, first discuss the changes with that person

There will always be improvements underway in the CHEFS code, and any new work must align with those improvements. The end goal of these improvements is code that is:

  • necessary (YAGNI)

  • correct (it works!)

  • simple (“as simple as possible but no simpler”)

  • easy to read

  • easy to understand

  • easy to modify

  • easy to fully test

  • consistent (to reduce cognitive load)

  1. Using the type from Conventional Commits, decide what the primary type of work is, such as feat for a new feature

  • build: change in build system or dependencies

  • ci: change in continuous integration / deployment

  • docs: change to documentation

  • feat: a new feature is being added

  • fix: an existing bug or defect is being fixed

  • perf: change to improve performance

  • refactor: change to improve code quality

  • revert: reverts changes in a previous commit

  • style: change to code style/formatting

  • test: add missing tests or correct existing tests

  1. Ensure that the main branch in your cloned fork is up to date

The fetch and rebase GitHub workflow used by Kubernetes is a common way to keep cloned repos in sync with the origin and upstream repos.

Note: Some people prefer to pull and create merge commits, and that’s fine because we squash commits when a Pull Request is merged into upstream/main.

  1. With an example Jira task FORMS-1234 that is a new feat, create a branch off your main with a name like feat/1234-new-map-component

You can name the branch anything you want, but:

  • the feat/ prefix groups branches of the same type in the tools

  • the task number 1234 makes it easy to find the corresponding ticket in Jira

  1. Crank out some code and tests (or tests and code, if you like TDD) and whatever docs are needed

  2. Run the unit tests using Terminal → Run Task... → Unit Tests and check the test coverage of your new code

Test coverage reports appear in:

  • Frontend: app/frontend/coverage/index.html

  • Backend: app/coverage/lcov-report/index.html

Refer to the backend unit test documentation for details on:

  • test writing strategy

  • running tests on the command line

  • running with and without the coverage report

  • running single specs or single tests

  1. Commit your code with a message like feat: FORMS-1234 new map component

It’s very important…