As a side project, I’m working on a ReactJS app that I’m hosting on GitHub Pages in a private repo. My build process is in Gulp and while I could have just pushed a dist folder containing my combined and compressed assets to the gh-pages branch on GitHub, this seemed like a bad idea. It would be much nicer if I didn’t ever have to think about the gh-pages branch. I’d prefer just making a change to the master branch and have this trigger an auto-deploy that builds everything and pushes that build to the gh-pages branch. With my custom domain pointing to this repo, a change to master is the same as a deploy to my website. Voilà.

It turns out that this is relatively easy to do, thanks to CI and CD services out there. In 2011 three big ones hit the market: Travis, Circle, and Codeship. Here’s a great breakdown of their pros and cons from StrongLoop. I started out with the first one, Travis. There’s an excellent gist that explains how to do it. It took me an hour or two to get all the kinks worked out but it’s a solid way of doing a deploy to gh-pages. If it weren’t for the fact that I want this to be a private repo project, I would have stayed with Travis due to how incredible the experience was. The problem is that Travis is pretty limiting on their private repos plan. You have 100 builds for free and the after that you’re paying $129/mo at the base plan. For a little side project that I’d still prefer to keep as a private repository, that’s really steep. I might consider doing $10/mo but certainly not $129. That’s startup territory.

Next, I skipped Circle altogether and turned my attention to Codeship. Circle only lets you have one concurrent container (or build) on the free tier, which isn’t as generous as Codeship’s 5. It’s nice having the legroom for creating a couple of more impulse side projects should I ever wish to, without having to break out the wallet.

Getting set up with Codeship was actually simpler than with Travis and that aforementioned gist. Here’s the general documentation for how to do it. I followed the first two steps exactly, but third step is a bit open-ended.

git  clone <the ssh link to your repo> dist
cd dist
git checkout gh-pages || git checkout --orphan gh-pages
cd ..
rm -rf dist/**/* || exit 0
npm install
gulp deploy
cd dist
git config "<the email address you used for your machine user GitHub account>"
git config "<the username you used for your machine user GitHub account>"
git add .
git commit -m "Deploy to GitHub Pages: ${CI_COMMIT_ID} --skip-ci"
git push origin gh-pages

This is a clever little set of commands, really. It’s creating a git repo inside of another git repo in order to handle the build correctly. I wish I could say I was the one who came up with this idea but the hat tip belongs to Domenic who gave me the idea with his Travis gist. A few things to note about this:

  1. This assumes that npm install; gulp deploy is the series of commands you use to combine and minify your assets. That’s true of my project but yours may be different (particularly the second one). Be sure to replace lines 6 and 7 with your actual ones (as well as the <placeholder> values, of course).
  2. This also assumes your output dir is dist. Hopefully it is, because that’s the convention, but if you’ve got something else, you’ll need to update lines 1, 2, and 8.
  3. There’s more hardcoding here than abstraction. These things could be lifted out of here into environmental variables but I tend to be a literalist with this stuff.
  4. I’m completely bypassing Codeship’s recommendation of handling the final git push via their own provided code (“include the commands from eployments/”). Not a big deal either way, I just don’t see the need for an extra HTTP request.

When you combine a smartly built front-end-only app on GitHub Pages with a Ruby on Rails app on Heroku, very cool things are possible on a shoestring budget. On weekends when I’m not doing freelance work, it makes for a very good way to keep my skills sharp while staying in love with what I do. This ties in with one of my favorite Steve Jobs quotes:

I have looked in the mirror every morning and asked myself: “If today were the last day of my life, would I want to do what I am about to do today?” And whenever the answer has been “No” for too many days in a row, I know I need to change something.

Fun side projects, ones you’re in complete control of, are a great way to stay fresh and excited with the tech we use Monday through Friday.