Deployment, deployment, deployment

One of the first things we did with Kwoosh was to build a pretty robust deployment process. It was probably a bit of an overkill at the time, but it was a fun project and a new challenge to throw ourselves into.

When starting the Workshop I copied a lot of the deployment process over, so lets take a look at how this site works.

The Workshop is a statically generated site using Jekyll. This means that its just a bunch of simple HTML files and a few images. There are no complicated databases, frameworks or scripts…at all.

We begin the process of writing a new post in a text editor and Markdown. We write simple posts that reflex our design and ethos and then commit them to a git repo. This is then where the magic happens.

Whenever we push commits to our master branch a web hook pings our deployment server to let it know there is something to do. Our development server runs Jenkins and this receives the ping and gets to work.

For all our deployment processes we have three stages. Build, test and deploy. We therefor have three jobs with these names within Jenkins that are run in that order.

For this site we only use Jenkins to call an Ant script where most of the work is done, and this also follows the three stages of deployment.

Build

In the build stage we build all the resources we need for the website.

Primarily this means that we call Jekyll and that spits out all the HTML files for the website. We then run our CSS through a linting process to check for errors and then minify it. If we had any JS we would also do the same at this point.

Finally we run all the image assets through a minification process using a series of different command line tools for each image type. This removes any un-needed data from the image files and reduces their file sizes…by up to 40-50% in some cases.

We then move all these files into a build directory so that everything is nicely organised.

Test

Normally we would then run a series of tests against the content in the build folder. We don’t yet have any for the Workshop, so this step is just skipped.

Deploy

If the tests all pass (which they do) we then begin the deploy process.

For this website that means uploading to Amazon S3. We use s3cmd to sync the HTML files to one bucket and the assets to another. It then invalidates the CloudFront cache, and after about 30 seconds and a refresh the new content appears on the site.

The whole deploy process takes about 15 seconds to process and then another 30 or so for CloudFront to start serving the new content.

And that’s it. All we have to do is write and commit. No messing around with FTP or updating Wordpress. We commit and go.