This website runs on Bluemix and is built with Hugo, a static site generator
written in Go. Pages are served directly by
hugo server which thinly wraps
the http package from Go’s stdlib.
The entire website setup is versioned by git including the Hugo binaries, continuous delivery scripts, content & assets.
Every local commit gets pushed to a Jazz Hub git repository. Our continuous
delivery environment, which runs on Jenkins, triggers a new build every time
there is a new commit to this repository. This translates to pulling the
latest version from Jazz Hub, running
cf push, checking that the new version
of the website is up and running and finally making it available to the public.
Widely known as zero downtime deployment, we call it Blue-Green deployment
since it describes the process more accurately.
After having considered WordPress, KeystoneJS & Ghost, we have settled on Hugo for the following reasons:
- a platform-specific binary file is the only dependency
- no database required
- fast feedback when creating new content
- fits perfectly with our way of working (version control, instant feedback, Continuous Delivery)
We could try other popular alternatives which needed a PHP & node.js
runtime with no effort. Rather than spending time with programming language or
database setup, we could focus on finding the solution which best met our
needs. Bluemix Containers came in handy while evaluating Ghost &
WordPress. As for KeystoneJS, a new instance was a simple a
cf push away.
Once we have settled on Hugo, we had continuous delivery and blue green deployment set within minutes. We can scale to as many app instances as we need with a single command. We went with the Go buildpack initially, then settled on a generic CloudFoundry binary buildpack as it made our deployment 50% quicker.
Why Continuous Delivery?
All Bluemix Garage projects are continuously delivered, without exception. Whether it’s a utility such as our Bluemix Blue Green Deployment, cf cli plugins, our website or any projects which we deliver for our clients, they are all developed using Extreme Programming practices.
No code is written before there is a failing test. We keep the cost of change low by continuously refactoring. We always pair program. We keep our commits small and constantly push to a central repository. Our Continuous Delivery environment pushes directly to production. We keep all feedback loops as small as possible so that we can quickly learn what works and what doesn’t. There is no better way of consistently delivering working software of the highest quality.