A Sandbox for Every Git Branch

We've all been in this situation: someone sends you a git pull request. You read it, and it looks pretty good. So you merge it, and deploy it to your dev environment. Aaaaaaand it's broken. Great, now you have broken code in your master branch. Better hope pull request #2 is better than #1.

How did both the repository owner and pull request author mess up so badly? The problem with this is two fold. First, the pull request author has to wait for the repository owner to act before they can test their code in the wild. Second, the repository owner has no where to test a pull request.

The solution is simple: disposable environments. Using Jenkins Continuous Integration, we built a system where every git branch is built into its own, stand alone website. It's kind of like having your own http://simplytest.me/. It works like this:

• When a developer starts work on a feature, they create a new branch off of master:

  with `git checkout -b feature/jira-123`

• When the developer is finished, he/she pushes the branch to github/bitbucket with:

  `git push origin feature/jira-123`

• Jenkins sees a new branch and goes to work creating a new website:

  http://feature-jira-123.dev.mysite.com

• The developer tests their code on their disposable sandbox site (spoiler alert, it's broken)
• The developer pushes again.
• Jenkins rebuilds their sandbox site.
• It works! Time to create a pull request.

In this detailed, hands-on tutorial, I'll show exactly how we built this, and how you can build your own.

Intermediate knowledge of git will be assumed for attendees of this talk.