Skip to content

Development and Workflow Tips

Jump to bottom Edit New page
Lance Pollard edited this page Sep 26, 2012 · 7 revisions

Setting up the Development Environment

To move on from submitting bugs to helping resolve existing issues or contributing your own code to Tower, you must be able to run its test suite. In this section of the guide you'll learn how to set up the tests on your own computer.

1. Install Prerequisites

1.1 Install XCode

XCode 4 is required for git to work.

It might require you to upgrade your operating system, so either find an older version of XCode or take the time to upgrade. It's better to get the latest version of XCode.

1.2 Install Homebrew

First, install Homebrew by following the Homebrew installation instructions (or just paste this into the terminal)

/usr/bin/ruby -e "$(/usr/bin/curl -fksSL https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb)"

1.3 Install Git

If you don't have git already, it's easy to install

brew install git

1.4 Install Node and NPM

brew install node

1.5 Install MongoDB

brew install mongodb

Then follow the instructions output in the terminal to start mongodb (mongod start).

1.6 Install Redis

This is optional since Tower is not using Redis yet.

brew install redis

2. Install Tower

2.1 Download Tower

Fork Tower and clone your fork

git clone git://github.com/<username>/tower.git
cd tower

2.2 Install node modules

The npm command uses the package-json file to determine and install dependencies similar to the Gemfile for Bundler in Rails. If you stand in the Tower root dir and run npm install all development dependencies should be installed globally.

npm install -g

2.3 Run the Test Suite

Now that you have everything installed and running, time to run the Tower test suite.

make test

Tower uses Mocha for writing tests.

Benchmarking

Stress Testing (Load Testing)

ab -n 1 -v 4 "http://localhost:3000"

Git Workflow

Mac Terminal Workflow

  • Each project gets its own terminal "window"
  • Each project should have at least these 5 tabs for optimal flow:
    1. Tab for the local server, if it needs a server (node server.js)
    2. Tab to manage git commits, so the server can be running and you can still commit.
    3. Production log, if there is a production version
    4. For installing plugins/modules/gems, so you can be waiting for an installation to complete while still developing on your local server and pushing to git.
    5. Tab to git commit and push your project wiki, so it stays up to date. Otherwise I've found you end up rarely syncing it to GitHub.

Git Workflow

Do all of your work on a development branch.

git branch development
git checkout development
# make changes
git add . ; git commit -a -m 'developed a new feature'
git push origin development

Merge with other people's development branch into yours

# link to somebody else's fork, call it "upstream" or "username-upstream" or whatever
git remote add upstream git://github.com/username/project-name.git
git fetch upstream
# when you want to pull their changes into your current branch
git merge upstream/development

Merge development to master 

git branch # "development"
git add . ; git commit -a -m 'finished feature in development branch'
git checkout master
git merge development
git push origin master

If you want to hack, create another branch

You can have as many branches as you want.

git checkout development
git branch hacks # create "hacks" branch
git branch node5 # create "node7" branch, where you're upgrading code to work on node version 5.

Use remote to push code to separate domains

Everybody calls GitHub their origin, so you do map the remote address to origin like this:

git remote add origin git://github.com/username/project-name.git

If you want to sync to somebody else's fork, you add another named remote:

git remote add lance git://github.com/viatropos/project-name.git

If you want to push your code to Heroku, you can add a heroku remote:

# heroku gives you this git address
git remote add heroku [email protected]:project-name.git

Ideally though, you have 3 branches of your project on heroku, and link remotes like this:

git remote add development [email protected]:project-name-development.git
git remote add staging [email protected]:project-name-staging.git
git remote add production [email protected]:project-name-production.git
pwd
# ~/documents/code/project-name
git branch
# development
git push development development:master
# pushes local "development" branch to remote "development" link's "master" branch

That last line is the most important part of git. To push a branch to a remote master, do this:

git push <my-branch> <the-remote-name-i-gave-my-branch>:master

Other helpful git commands

# check current branch you're on
git branch
# list all remote branches you're connected to
git remote -a

Notes

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.

Useful Git Snippets

Create empty GitHub Pages branch

git clone <repo>
cd <reop>
git symbolic-ref HEAD refs/heads/gh-pages
rm .git/index
git clean -fdx

If you have submodules and get something like this:

git submodule update
Cloning into wiki...
remote: Counting objects: 1998, done.
remote: Compressing objects: 100% (1008/1008), done.
remote: Total 1998 (delta 1166), reused 1710 (delta 901)
Receiving objects: 100% (1998/1998), 486.96 KiB | 317 KiB/s, done.
Resolving deltas: 100% (1166/1166), done.
fatal: reference is not a tree: af9917a0528dea3a5187b462ca778715b5f4b382
Unable to checkout 'af9917a0528dea3a5187b462ca778715b5f4b382' in submodule path 'wiki'

It's because you haven't pushed your local submodule changes to the remote repo (fatal: reference is not a tree).

Link the GitHub Wiki to Repo

git submodule add git://github.com/you/proj.wiki

Resources

Add a custom footer
Clone this wiki locally