Refactoring Our Development Workflow

10 June 2015

When Plain was at 7 people we had a pretty great development workflow for fixing bugs and deploying new features for Barley. However, with just Kyle and I — working side-by-side — we do not need our development workflow to be nearly as complex.

Last week I tied myself to my chair and refactored our development workflow and we’re really happy with the results so far. Here are just a few of the benefits:

  • We went from 3 code repositories to one. Our code used to be split between the core application (API, syncing, etc.), our front-end code for the UI (Site Bar, Account Manager, various modals), and the editor (the toolset used for inline editing). Now we have a single repository which is much easier to manage and deploy.
  • We no longer need to run our importer for our front-end code. Our template importer (or sync process) was used for two reasons; first, we allowed customers to “sync” their templates with Dropbox, second, we used it to import our front-end code into the core application. This process would manipulate the HTML, move the files into their appropriate locations inside the application, and even compile CSS and JavaScript. Now we’re using Grunt to do any compiling we need to do (only for our Staging and Production environments) and locally we do not need to run any compression or syncing at all. To put it simply; this speeds up our local development dramatically.
  • Our files and folders now follow a single naming convention. We had underscores in some places, dashes in others, and camelCase still in others. We went with dashes everywhere and this makes it much more simple.
  • We deleted a huge amount of unused code, fonts, and libraries. Since our code was spread out over 3 separate repositories we ended up with various libraries being duplicated, a lot of test files here and there to test things locally before we ran our import process, and a bunch of other dead code from our beta period. That is all long gone now.
  • We also fixed up a bunch of little niggles that were like thorns in our side. I’ll give you one example; we use Vagrant to run a local development environment. For the last two years Kyle hasn’t been able to run it and there were a few small oddities with the image that kept erring. We’ve fixed most of these and now we can get down to work without a myriad of headaches.

These are just some of the many benefits that we’ve seen from cleaning up our development workflow. We should do this once every few months.

Follow Along:   @getbarley |

Join Our Mailing List:

Activate Site will become accessible to the public