Skip to content

6. Development Workflow

Jump to bottom
designbygio edited this page Feb 4, 2021 · 9 revisions

Current workflow

  1. Go to Projects
  2. Find a task you are interested in and assign to your self
  3. Move task to In progress column when start to work on it
  4. Pull last changes from develop branch
  5. Create a new branch from develop following our branch naming convention (follow below)
  6. Start writing code following our best practice (follow below), create tests if required from your changes
  7. Commit your changes and fix possible issues raised by linting tools
  8. Run tests and ensures they are all passing
  9. Build the project locally and ensures it doesn't fail
  10. Push your changes on a separate branch
  11. Create a Pull request against develop
  12. Assign PR to your card in Projects board
  13. Wait for Pull Request approval or comments. Merge the branch once is approved.
  14. Merge branch with Squash merge option
  15. Move card in Review column [TO APPROVE]
  16. Check your changes on staging [TO APPROVE]
  17. Once the tester will approve your changes, the changes will be merged to production and your code will be live! 🎉 [TO APPROVE]

Staging

Here you can find the current staging branch. Please review your code there once it gets merge in develop branch. Check all the possible part of the application that are involve in the merged changes. https://elliotforwaterstaging.azurewebsites.net

Best Practice

  • Make small PRs as much as possible. Big Pr are difficult to review and to merge if the code keeps changing.
  • Commit your work often, as we are multiple developers on the same project.
  • Merge from develop as often as possible especially if working on a long running feature to help avoid large merge conflicts.
  • Try to review other pull requests when you can to improve understanding of the project, please comment on the code if you have a question or see an issue.
  • Feel free to open a work-in-progress PR to start to get early feedbacks. You can append the prefix [WIP] to your PR so other devs knows it shouldn't be merged yet.
  • Each PR must have a test (if makes sense with the changes). A PR without test will not be approved.
  • If you are working on UI component, a story for this UI element is expected in the PR in order to be approved.

PR and commits naming convention

A branch and commit message must have a meaningful name/title that describe which changes are applied. This is very important in the case we need to revert some changes, fix git history or extract a buggy commit.

Branch name must follow these conventions:

  • feat: new feature
  • fix: a bug fix or a quick fix to the code
  • chore: Regular code maintenance
  • refactor: code refactoring

i.e. feat-edit-profile-page i.e. fix-undefined-empty-users-list

Same convention is used for git commits: <type>: <verb in present-tense> <rest of message (max 80 char)>

i.e. feat: fetch user data and display in profile page

Tests

Test are covered with Jest. you can run tests with npm run test

If you are working on test is better to run npm run test:watch. In this way each changes will be detected and the test will run again.

Unit Test are very welcome. Please use snapshots just when makes sense.

Clone this wiki locally