One of the first things we did withKwooshwas 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 usingJekyll. 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 andMarkdown. 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 runsJenkinsand 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 anAntscript where most of the work is done, and this also follows the three stages of deployment.
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.
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.
If the tests all pass (which they do) we then begin the deploy process.
For this website that means uploading toAmazon S3. We uses3cmdto sync the HTML files to one bucket and the assets to another. It then invalidates theCloudFrontcache, 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.