Skip to content

6. Development Workflow

Jump to bottom
designbygio edited this page Oct 20, 2021 · 9 revisions

Current workflow

  1. Go to Issues
  2. Find a task you are interested in, comment on it tagging @ElliotForWater/elliotforwater-core-devs and ask to be assigned to that issue.
  3. Pull last changes from develop branch
  4. Create a new branch from develop following our branch naming convention (follow below)
  5. Start writing code following our best practice (follow below) and our code guideline, create tests if required from your changes
  6. Commit your changes and fix possible issues raised by linting tools
  7. Run tests and ensures they are all passing
  8. Build the project locally and ensure it doesn't fail
  9. Push your changes to your custom branch against develop
  10. Open a Pull Request against develop
  11. Link your PR to your Issue
  12. Wait for Pull Request approval or comments.
  13. Merge your PR with Squash merge option, once is approved by Elliot For Water team member
  14. Once the tester will approve your changes, your PR will be merged and your code will be live soon! 🎉

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