Versions Compared

Version Old Version 6 New Version 7
Changes made by

Walter Moar

Walter Moar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleWhat does this mean?

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 - don’t maintain, document, test, etc, code that we don’t need)

  • correct (it worksshould work!)

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

  • documented

  • easy to read

  • easy to understand

  • easy to modify

  • easy to fully test

  • consistent (to reduce cognitive load)

Information that everyone should be familiar with:

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

...

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

  2. Periodically commit your work with messages like:

    Code Block
     feat: FORMS-1234 description of the change
 
 This is the body of the commit message and provides more detail for anyone
 in the future who is looking into this commit.
Expand
titleWhy this format is mandatory

We want everyone to use this standard way of writing commit messages so that in the future we can use them to automatically generate a changelog.

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

Expand
titleEverything you ever wanted to know about the unit tests

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

...

titleWhy this format is mandatory

...

  1. Publish your branch

  2. Create a Pull Request (format, draft, read diff)

  3. GitHub Actions

  4. Do a self review (diff)

  5. (somewhere above: limit size of change)

  6. Run the deploy Action

  7. test

  8. Mark as ready for review

  9. Add reviewers

  10. Talk to reviewers

  11. Keep up to date

  12. Deploy Action

  13. merge and message

  14. Push Action

  15. Undeploy Action

  16. Code Climate / etc?

  17. Jira: moving tickets, rewrite description