Table of Contents
So, you want to do some contribution for iPeer project. Just follow the following steps to make your own local development environment.
For External Developers and Contributers
- Get a GitHub Account from https://github.com.
- Install Git on your local computer.
- Fork the iPeer project (https://github.com/ubc/iPeer) into your account and clone the code from your forked repo: http://help.github.com/fork-a-repo/
- Additional steps to set up
- Pull the Guard plugin.
cd ipeer git submodule init git submodule update
- Pull the Guard plugin.
- Setup coding standard
- Starting developing~
- Once you finished, you can issue a pull request so that we can merge your changes to the iPeer repo. http://help.github.com/send-pull-requests/
For Internal Developers and Contributers
- Follow steps 1 and 2 for External Developers and Contribuers above
- Follow the steps in https://help.github.com/articles/generating-ssh-keys to generate a ssh key for your github account
- Clone the code
git clone firstname.lastname@example.org:ubc/iPeer.git
- Additional steps to set up. Pull the Guard plugin.
cd iPeer git checkout dev git submodule init git submodule update
- (XAMPP) go to xampp/htdocs/app/plugins/guard/config, open guard.php. You will have to do something similar if you are using any other web server.
- Make the following changes
//$config['Guard.AuthModule.Name'] = 'Shibboleth'; // Using Shibboleth module $config['Guard.AuthModule.Name'] = 'Default'; // Using default (build-in) module
- Copy guard.php to xampp/htdocs/app/config
See, that's not very hard.
For version 2.x
To turn on debug mode, change the line in file app/config/core.php from:
For version 3.x
To turn on debug mode, create a local configuration file under app/config/config.local.php with the following content:
Running Vagrant (Virtual Environment)
Follow the instructions in https://github.com/ubc/iPeer/blob/dev/readme.md#running-virtual-development-server.
In order to run tests, you will need Phing and OAuth (required to run controller tests). You also need to set up a test database, named the same as your database in app/config/database.php with suffix "_test", e.g. ipeer_test.
To run the tests, simply call the following commands at the root of the directory:
Branches in public repo and the purpose of each branch:
- 2.x: iPeer 2.x code base. Each commit on this branch will be a new version to release.
- dev: The branch we are working on day to day
- master: iPeer 3.x code base. Each commit on this branch will be a new version to release.
You can/should create local branch if you are working on a new feature or non-trivia bug fix. Then merge back to dev. You may use rebase or not depending on the complexity of the work.
- Any push to 2.x branch will trigger iPeer2 job. If the job success, iPeer_Release_2.x will be triggered and will publish a new version for 2.x.
- Any push to master branch will trigger iPeer3 job. If the job success, iPeer_Release_3.x will be triggered and will publish a new version for 3.x
- Any push to dev branch will trigger dev job. No release will be published.
Old and new branches mapping (branches renamed as of Nov 18th, 2012)
- master -> 2.x
- cakephp1.3 -> dev
- cakephp1.3 -> master
- removed compatibility branch
NOTE: The branching strategy we are using is based on the page: http://nvie.com/posts/a-successful-git-branching-model/.
The standard workflow is as the following:
- Pull the latest code
- Depending on the task, work on dev branch or create a local branch. Use frequent branching and small commit. Do not combine several tasks into one commit.
- Write some code
- Rung unit tests and integration tests
- Run your own manual tests
- Merge back to dev branch (not necessary if working on dev branch)
- Push the changes to github
- Close any related tickets if there is any
When a push is send to Github, it will trigger a build command on the continuous integration server. It will run the tests and checking, e.g. styles, code duplication, etc, to make sure everything works fine. If the build is failed, you should exam the code and fix it.
If the build is successful, the CI server will deploy the code to our test server for further testing. Different branch will be deployed to different domain.