Versions Compared

Version Old Version 13 New Version 14
Changes made by

Walter Moar

Walter Moar

Saved on

Key

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

...

  • Channels where we receive input

  • How we choose work to be done

  • UX design

  • UI design

  • Jira

  • Sprint planning

  • …and everything else leading up to…

Development

We follow the development process below to have:

  • Code changes that follow the design and style of the existing code

  • Code changes that

  • Commit messages in a consistent format

  • Pull Requests in a consistent format

  • Pull Requests that are easy to review

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

  1. Make sure that the Jira task is broken down into small piece(s) of work

Expand
titleWhat makes a good Jira task

The goal for all developers is to create Pull Requests that are easy to review. Avoid:

  • tasks that are too large

  1. Make sure that the Jira task has a clear description, and then move it to In Progress

Expand
titleWhat makes a good Jira description

Ideally the description in the Jira task is written in a way that it can be copied and pasted as the description of the Pull Request. This is very subjective, but the description should:

  • Clearly describe the change that is needed

  • Be written in plain language - if it’s very technical then perhaps add a “Background” introduction that explains things in plain language

...

  1. Crank out some code and tests (or tests and code, for TDD bonus points) and whatever docs are neededdocumentation that needs to be created or updated

  2. Periodically commit your work with messages like:

    Code Block
     feat: FORMS-1234 new map component for dropping a pin
 
 Added a new map component that allows the user to drop a "pin" on the map,
 and the location is saved as both Lat/Lon andor UTM coordinates.
Expand
titleWhy this format is recommended

It’s only a recommendation that “working” commit messages use this format , as - these commit messages will eventually be squashed (, and it’s only the final commit message that must be in this format). So it’s It’s a good idea to always use this format so that we are used to to be familiar with how the final commit message must look.

Tip: In the VS Code commit message input box, the up arrow allows you to scroll back through previous commit messages

  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. Publish your branch, for example using the “Publish” button in VS Code

  2. Create a Pull Request (format, draft, read diff)GitHub Actionsfor your branch, for example using “New pull request” in the GitHub web site

  3. Do a self review (diff)

  4. (somewhere above: limit size of change)

  5. Run the deploy Action

  6. test

  7. Mark as ready for review

  8. Add reviewers

  9. Talk to reviewers

  10. Keep up to date

  11. Deploy Action

  12. merge and message

  13. Push Action

  14. Undeploy Action

  15. Code Climate / etc?

  16. Jira: moving tickets, rewrite description

...