- Meteor 1.7.0.5
- React 16.4
- Redux 4.0
- Saga 0.16
- Required: Change the project name in package.json file
meteor npm install yarn -g: Install yarn for meteor commandyarn dev: Run the project and start coding
Note: Please always user meteor yarn instead of yarn standalone
Root
|-client
|--|-head.html
|--|-main.js
|
|-imports // All of potential code will be here
|--|-api
|--|-lib
|--|-startup
|--|--|-both
|--|--|-client
|--|--|-server
|--|
|--|-ui // All of front-end code will be here including React, Redux, Saga
|--|--|-actions
|--|--|-components
|--|--|-containers
|--|--|-helpers
|--|--|-layouts
|--|--|-pages
|--|--|-reducers
|--|--|-sagas
|--|--|-store
|--|--|-stylesheets
|--|--|-utils
|
|-server
|--|-main.js
|-public
- TODO here
- User roles
- Current journey map
- Future journey map
- Epics (All / Open )- representing a high level feature set that is typcially delivered across multiple sprints.
- Stories (All / Open ) - representing specific testable user or system requirements that can usually be implemented in one sprint.
A Behaviour Driven Develpment (BDD) model is at the heart of the testing frameork.
A highly automated continuous delivery pipeline based on the Code On Tap is used for confident deployment of new features.
Is done with tickets.
This project uses the git forking workflow, https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow And git-flow, https://bitbucket.org/zigvy/git-flow/src/master/ or https://jeffkreeftmeijer.com/git-flow/
It's OK to leave questions hanging in slack, for someone who isn't there at the moment but will be later. So each shift should start with a review of slack, "question grooming" activity, along with the usual ticket-grooming.
Clone the repo, commit frequently, make a PR for dicussion early (and if you think it's ready to merge then say so).
Try to push to your commits at least once an hour, and write commit messages "in the imperative mood". Read this if you haven't already: http://chris.beams.io/posts/git-commit/
Each commit should do one thing. It's no problem making lots of small commits, it's actualy much better than infrequent large commit because they are easier to review.
We use the Pull Request system of github. You first need to fork the repo.
For creating a PR please follow this :
- Fetch the upstream master & develop :
git fetch upstream/master && git fetch upstream/develop - Switch to
developbranch. - Create a new clean branch :
git checkout --track -b myNewBranch upstream/develop, a good practice is to following git-flow ( you should not use the master of your own remote (origin) as a dev branch , your master should be equal to theupstream/master) - Do your work, make commits, you should create directly a PR and push your work frequently.
- If other devs push commits , you should rebase your own branch. you fetch again
git fetch upstream/developandgit rebase upstream/develop( you can also use the interactive rebase to squash your commit into onegit rebase -i upstream/develop) - If you have conflict , you have to resolve each conflict on each commit , do it manually or add
kdiff3/Beyond Compareor anything that fit you , add these modification and dogit rebase --continueuntil you cleared the conflicts. - Test your code.
- You can now push your code , if the branch is new you just do git
push origin myNewBranch, if you had rebase you need to force thepush git push origin myNewBranch -f - Create the PR , with a new branch github detect it automatically you should see a yellow bar on main page. MOST IMPORTANT, point the PR to
developbranch - When the PR is merged , delete you local and remote branch
More you rebase your branch often, less you get problems. So don't wait ! You should rebase each time a commit is added to the upstream/master.
DISCLAIMER : Use push -f only with Fork and PR project like here, never on a project were everyone is working on the same remote. Your rewrite commits history.