One of the many first-world, developer-related problems that I’ve been discussing lately is the way we handle website compilation and deployment. I’m a big fan of development automation and robust boilerplates, so it pains me to see people using new tools and knowledge to build really great websites and then degrade themselves by using FileZilla to update their site.

The predicament

The real reason I started thinking about this, however, is twofold. Firstly, I’m always looking for ways to automate everything (as per Lestrade). Secondly, I use GitHub Pages to host most of my websites and projects since it’s free and I can instantly deploy updates by pushing to the repository.

The issue is that Yeoman, Lestrade and other automation tools don’t play nice with your average deployment strategy since they compile to a distribution folder. This can be a hassle if you’re using GitHub Pages as it doesn’t let you serve from a subdirectory.

This means I end up circumventing my normal workflow in one of two ways, both of which I hate. The first is just not using an automation tool and writing raw HTML, CSS and Javascript — no scalability, compression or automation of any kind. The second is restructuring the tool to compile in the root directory, e.g.

.
├── source
│ ├── index.jade
│ ├── scripts.coffee
│ └── styles.less
├── index.html
├── scripts.js
└── styles.css

Both of these methods suck, so I found a new solution. However at the same time, I also had a look at the way we deploy websites, web-apps and Wordpress / Ghost themes, so I figured I’d share what I came up with.

Deploying a website or webapp automagically really depends on the web server or platform you’re using more than the language or framework. In order to explore this though, we’ll have to look at each strategy individually and assume that we’re using a deployment tool like Yeoman or Lestrade:

Websites or web applications

The best solution I found for deploying websites or web applications on a web server is installing Git on the server, cloning your repository and configuring the web server to serve distribution files as the root directory.

From here, you can either pull from the repository on demand and run your build system to update the site, but I’ve heard Paul Irish talk about writing a script that pulls the repository each time a commit comes in (haven’t found a good script yet). Combine this with a decent branching setup and tie the script into your build system and you won’t have to touch a thing!

The previous example assumes that your web server is decent and has Git and Node.js installed. My old hosting provider was fairly low-end and didn’t allow a Node installation, so I came up with a different strategy for that.

The lack of a Node.js (or even Git) installation only means that you won’t be able to compile your files on the server. We can still compile the files locally (into a Git-ignored folder) and extend our build script to upload the files via FTP, using a plugin like gulp-ftp for Lestrade.

Ghost / Wordpress themes

Depending on your setup, themes may require a bit of effort on your part. If you’re running something like Ghost or Wordpress on your web server, then the deployment strategy shouldn’t be much different from the limited web server we discussed.

If you’re running Wordpress, deploying your theme is as simple as running the build system and configuring gulp-ftp (or the equivalent) to push the distribution files to the appropriate theme directory on your web server:

wordpress/wp-content/themes/yourtheme

Same deal for Ghost, except you’d be uploading to a folder like:

ghost/content/themes/yourtheme

That’s the easy solution. The hard part is when you’re using Wordpress or Ghost’s hosted platform to run your website. While it’s currently not possible to upload custom themes to your Wordpress hosted site, Ghost(Pro) allows a zip file theme upload through your dashboard.

While we can’t automate the upload of this (or maybe we can — we should look into this later), we can definitely package the distribution files into a zip file for uploading. Just grab a plugin like gulp-zip if you’re using Lestrade, do some basic configuration and you should be good to go.

If you want to be really efficient, use something like gulp-open to open the dashboard page after you’ve finished building the theme.

GitHub Pages (or really limited servers)

Now we come to the finale of our deployment trifecta with possibly the most constricted (but definitely easiest) platform for hosting websites, blogs or web applications: GitHub Pages. The solution discussed here also applies to web servers with really limited configuration capabilities.

Basically as we’ve mentioned before, GitHub Pages doesn’t allow you to serve from a subdirectory, define any server configuration or FTP files. The heavily simplified architecture is my preferred medium of hosting but doesn’t appreciate how I like to build websites.

Luckily, we have a solution. Like the aforementioned limited web server strategy, we compile our website or web application locally but we use a plugin for Lestrade called gulp-gh-pages (or a Grunt equivalent for Yeoman) to deploy our distribution files to a new branch. This isn’t the cleanest solution since we have compiled files in the repository but at least it’s only affecting a single branch and doesn’t mix with our source code.

We’ll use our typical child branches for development (development, staging, production, etc.) but have another orphan branch for distribution. While each of the typical branches have the source code only, the new orphan branch has the distribution code only. If you’re using GitHub Pages, this orphan branch would just be gh-pages. If you’re on a custom server, just checkout to this new branch or set it as default on GitHub.