in Projects

Drawing app deployment – production build folder on separate repository

When I was building my drawing app I wanted to keep everything on a private git repository on bitbucket. I ran into an issue when I needed to deploy my build folder to production.

The issue.

My site is entirely client side javascript and has no server code. This means that it doesn’t make any sense to deploy an app to heroku and deal with the wrath of startup speeds or having a node server that just serves static files.

I decided to use github pages as my CDN which meant that I needed to deploy my production files to a github repository while being extremely careful that I never pushed source files that were not minified.

Screen Shot 2014-09-05 at 10.20.19 AMThe branching strategy I like to follow is the one outlined here. You have a master branch that is always ready to be deployed and a development branch. I needed to keep that in mind to be able to have different versions in my build folder depending on what branch I am in.

My basic file structure:

The solution.

The basic premise of the solution is to have the base folder which contains everything track bitbucket and the build folder track github. This is as simple as cding into the build folder and calling git init and setting it up as if it was any other github repository.

The interesting part is the actual build script that keeps everything connected. The build script also reads the version specified in my html file so that it can tag the commits in both repositories correctly and send version numbers to Rollbar for issue tracking.

Here is the deploy script in its entirety, I’ll break it apart after:

  • Step 1. We need to make sure we are on the development branch to keep silly errors from happening by accidentally starting on master. Note: We should probably also be checking that our working directory is clean.
  • Step 2. We need to create a new branch to be able to build our production files on. In the Nvie branching article, these are like the release branches used to make all of the last minute changes. In my case, that is to only run grunt to minify and clean my build directory.
  • Step 3. I need to pull out my version number from my html file. This version number is specified by my grunt build step and is set in code so that I can reference it from javascript for google analytics, Rollbar, and other comparisons I need to have it for. That regex pulls it out of <body ver="38181823">
  • Step 4. Commit the built files to the build branch and merge it into master. The merge flags make sure that in case of a conflict, it should overwrite the things in master.
  • Step 5. Send the sourcemap up to Rollbar and then delete it since we don’t want to deploy the sourcemap to github.
  • Step 6. Go into the build folder which is the git repo we set up before to track github and commit all of the files.
  • Step 7. Go back to the development branch and delete the build branch.
  • Step 8. The script optionally deploys to github pages and will send Rollbar a notification that a new deploy happened. By waiting here for user input I have a chance to go and test the build and do last minute verifications.

The results.

This build and deploy pattern gives you repository pictures like this.

The main repository:
Screen Shot 2014-09-05 at 10.03.27 AM

And the build repository that is sent to github:
Screen Shot 2014-09-05 at 10.24.30 AM


The graph for the main repository looks a bit silly because it is constantly switching between branches, however this is only because I was deploying after each commit as I fixed some last minute things. Normally the graph has a longer chain on the development branch and then has the two commits for release.


This script is definitely not perfect but it did work great for my needs. The biggest issue I have with how things are set up is that my build folder either contains development files or minified files depending on what branch you are in. That also means that every time someone commits on development they are also committing the built files. With a larger team I could definitely see that leading to constant merge conflicts.

I also want to have my release branches be called release-VERSION_NUM but the version number gets set on the HTML file during the grunt build step which needs to happen on that branch.


Write a Comment