In this project the group will work as a team, using Ruby on Rails, to build an online commerce platform.
- Learn to work as a team on a shared project
- Gain experience using a shared project workflow, using:
- Become familiar with the following technologies:
- Use TDD to drive all layers of Rails development including unit, integration, and user acceptance tests
- Utilize Travis-CI as a continuous integration service
- Practice mixing HTML, CSS, and Rails templates to create an inviting and usable User Interface
- Differentiate responsibilities between components of the Rails stack
We're using github for all of our source code hosting. To get started and join the fun:
- Create a free github account
- Contact us and request to join the group
- Check our Pivotal Tracker project
- Do some work
- Submit a pull request
See our Workflow section for more details.
This project is publicly tracked using Pivotal Tracker. To participate:
- Signup for a free Pivotal Tracker account
- Check out the project page
- Join the project by clicking red the
We'll process your request from there.
Also be sure to check out the documentation on SCM Post Commits for linking your commit messages to story IDs.
If you decided to maintain a personal fork, you'll probably want to use Travis-CI for it, which is awesome! It's always good to have more continuous testing. The project is already setup (http://travis-ci.org/ScrappyAcademy/store_engine) to work on Travis. All you need to do is (per the getting started doc):
- Sign in to Travis-CI with your GitHub account.
GitHub will ask you for granting read- and write access. Travis CI needs write access for setting up service hooks for your repositories when you request it, but it won't touch anything else.
- Activate GitHub Service Hook
Once you're signed in go to your profile page. You'll see a list of your repositories. Flip the on/off switch for each repository that you want to hook up on Travis CI. Then visit the GitHub service hooks page for that project and paste your GitHub username and Travis token into the settings for the Travis service if it is not already pre-filled.
If your repository belongs to organization or flipping the switch did not set up the hook, please set it up manually on GitHub, it will take just a couple of minutes.
- Push to your GitHub repo.
Now whenever you push to your personal fork, all of tests will be run on Travis and you will get an email telling you if they passed or failed. We suggest you still run your tests locally, and often (TODO: link to blog post on autotest), as you develop.
Since the team is largely distributed and needs to work asynchronously, the GitHub workflow seems the best fit to meet these needs. The workflow boils down to:
Everyone has full access
Use the campfire chatroom
- This provides a central location for communications
- It serves as a living transcript of our process
Anyone can pull any story to work on
Pair programming is highly encouraged (thus multiple people can work on the same story)
Master is always deployable
Keep branches simple
This is the base foundation for shipping working software:
Decide to work on something by checking Pivotal Tracker or a new idea you think would be awesome (put it into the tracker)
Branch off master
$ git checkout -b myfeature master
Regularly commit and push to the server
$ git push origin myfeature
If you're not sure about a small chunk of code, create a gist then post it in campfire / google group. Or just open a Pull Request.
Open a Pull Request**
Merge with master after review and delete branch if it is done
If working locally, merge with a no fast forward when possible:
$ git checkout master Switched to branch 'master' $ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 05e9557). $ git push origin master
Wait for Travis to report all tests pass
** "Pull requests are dicussions, that improve code quality" - Zach Holman How Github Works
While this frees up time from micromanaging, we are still learning, and want to learn together. So we will have code reviews (for now) before merging. The review process is simple:
- Once you want something to go back into master submit a pull request
- Email notifications will be sent, and messages added to campfire. As soon as a majority of people sign off on it (fun time to use Emoji you can merge
- If there is something more, group feedback will be provided to help guide you; or we can submit it for a group pair session the following week
If you need some help on various topics check out the tutorials below:
- Git & Git Workflow