Difference between revisions of "System Admins & Code Reviewers"
|Line 79:||Line 79:|
==Team Members ==
==Team Members ==
Revision as of 12:26, 18 April 2015
This section contains tasks associated with system admins and code reviews. Please add technical reviews based on the code submitted on GitHub.
- Add Technical Reviews and Suggestions
- Please include the link to module
Targeted Modules & Focus
- User Management
- Create Account
- User Roles
- User Profiles
- Dashboard for workers
- List of Available jobs
- Selecting a desired job.
- Executing & Submit the job
- Profile with list of jobs completed and payment accumulated.
- Publish tasks
- Dashboard for requestors
- Create Project & design Tasks
- Create Qualification
- Publish Tasks
- Review Results
- Mechanisms for viewing the jobs that workers executed.
- Profile with list of jobs that were requested and the amount of money spent on each.
- Mockup Designs supporting above functionalities
System Admin Activities
- Provision database for testing
- Create / maintain replica setup, backups
- Set up monitoring if database goes down
- Enable south and set up migrations
- Provision Django with Gunicorn and Nginx.
- Run multi process python server with Gunicorn and have it load balance
- Set up restart and monitoring on server in case of errors / failures (pagerduty)
- Manage users and permissions (ideally primary and backup only)
- Set up code repository on github and structure for forking repositories
- Check DB level code reviews
- Perform migrations for schema level code changes (with Django models)
- Ensure migrations DO NOT crash the database
Technical Reviews & Suggestion
- We are starting off with Heroku for Django + PostGres
- In the future, we might migrate to provisioning our own Dbs and servers, caching etc
- Heroku enables easy scaling of servers and dbs, we will be using 1 instance (cheapest plan). It also provides South support for Django.
- Users will be maintained through the native Django interface
Collaborating on Github
Our collaboration is based on GitFlow: http://nvie.com/posts/a-successful-git-branching-model/
There are two main branches:
master branch should always reflects a production-ready state.
develop branch is where we all working on the next release.
If you want to create a module or feature, it is encouraged to use your own branch and name it using
feature-* prefix, e.g.:
feature-vote to create a feature that enable user to vote in the system.
feature-review to create a feature that enable user to make a review in the system.
After you're done with it, you can merge to
develop branch using
--no-ff (no fast forward, so it will retain the history of commits).
- Lead Kristiono Setyadi