Overview

Welcome to the Scrappy Academy's group project tackling Store Engine from JumpstartLab.

In this project the group will work as a team, using Ruby on Rails, to build an online commerce platform.

Goals

• Learn to work as a team on a shared project
• Gain experience using a shared project workflow, using:
  • GitHub and esp. pull requests
  • Pivotal Tracker for task, story, feature, bug management
  • Heroku for site hosting
  • Campfire for collaborating
• Become familiar with the following technologies:
  • RVM
  • Bundler
  • Git
  • Rails
  • Rspec
  • Sass
  • Haml
  • CoffeeScript
• 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

Getting Setup

GitHub

We're using github for all of our source code hosting. To get started and join the fun:

1. Create a free github account
2. Contact us and request to join the group
3. Check our Pivotal Tracker project
4. Do some work
5. Submit a pull request

See our Workflow section for more details.

Pivotal Tracker

This project is publicly tracked using Pivotal Tracker. To participate:

1. Signup for a free Pivotal Tracker account
2. Check out the project page
3. Join the project by clicking red the JOIN PROJECT button

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.

Travis-CI (Optional)

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):

1. 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.

2. 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.

3. 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.

Heroku (Optional)

TODO

Workflow

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:

  1. Decide to work on something by checking Pivotal Tracker or a new idea you think would be awesome (put it into the tracker)

  2. Branch off master

     $ git checkout -b myfeature master

  3. Work

     • 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.

  4. Open a Pull Request**

  5. 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

  6. Wait for Travis to report all tests pass

  7. Deploy immediately

** "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

Tutorials

If you need some help on various topics check out the tutorials below:

• RVM
• Bundler
• Git & Git Workflow
  • Try GitHub
  • Common Git Practices
  • GitHub Flow
  • How GitHub Works
  • How GitHub Uses GitHub to Build GitHub
  • Product Design
  • Pull Requests 2.0
• Heroku
• Rspec
  • RSpec and BDD
  • RSpec Practices

Contact Us

• GitHub: https://github.com/ScrappyAcademy
• Twitter: Sir Scrappy
• Google Groups: https://groups.google.com/d/forum/scrappyacademy