A drawing of a mountain ridgeline.

Ridgline

It's taken me a while to narrow in on my current workflow (and of course, it's constantly evolving), but I'm very happy with what I've come up with. Sometimes the assets I create just get passed off to other developers, and other times I need to take on the task of deploying the website and manage their hosting; it all depends on where the company is in their development.

The Requirements

The goals I set for my development environment are:

  1. It needs to work for me, first and foremost. No compromises here, because a workflow that doesn't work for the creator isn't going to work for the client.
  2. It needs to integrate into any other technology stack. Since I often work with early-stage startup companies who's technology stacks vary widly between one another, I make a point to ensure that whatever I create can integrate into any other setup.
  3. It needs to be easy to share. No client wants to get a Zip file in an email with intructions on how to open "index.html".
  4. It needs to be simple. One look at the 'scaffolding', and you should be able to see what happens when you run "build", and how to make adjustments for the next project.

Through the process of evolution, I've landed on is a simple local development server build on Node, which I call Ridgeline. Ridgeline can be quickly (as in one-click quick) deployed to a live server, and it also generates static assets that can be used in any other environment.

The Process

I want to share the main features that make Ridgeline so great. If anyone wants to look at the code, send me a message and I'll be happy to share.

Server.js

Nothing special here, really. Just a simple Node v0.11 server with the help of Koa. It basically just handles the routing, and serves the static assets. To expand on it, I wrote a blog module that can be dropped in, email notification module,

Gulpfile.js

This is where most of the magic happens. Gulp is a task runner who's syntax prefers code over configuration (simple functions chained together as opposed to a JSON-like config file ala Grunt). Without diving into the code, the main tasks are:

  1. Grabs any files installed with Bower, and optionally concatonates them into one file (fewer requests) and dumps them all into the public folder.
  2. Grabs all of the local source files (compiles and concatonates SASS/Jade/etc.) and dumps them all into the public folder.
  3. LiveReload support in the development environment (more on that below).

The features above are slipt into two modes: development and production. Development mode includes file watchers to make LiveReload work, and generates non-minified versions of files. Production mode will minify, gzip, etc. files when necessary, and avoid the unnecessary "watching" for a smaller memory footprint on the server.

Production mode also passes variables into the Jade compiler, which are used to conditionally switch script tags over to public CDN versions. The thinking here: keep everything local for local development, and use CDN versions when possible in production.

Moving Forward

I'm really happy with Ridgeline as it is, but it is also made just with me in mind. I do hope to make it open-source, but before that I need to make some of the code a little more user-agnostic. If anyone wants to take a look at the code and help open it up, reach out to me! elliott@elliottregan.com.