How we do: Deployment

Deployment can be a tricky topic to tackle. You want ease of use, reliability, speed and consistency, right?

The trouble is that many deployment strategies can be burdened by a slew of good ideas that don’t quite work, pipelines that have been set up in the wrong way for your project, or tight coupling to different applications that aren’t always in your control. THE OUTNET Tech team have come up with an interesting approach that has been working very well for our front-end JavaScript bundle applications, which I’d like to show you.

We have many apps written in React, Polymer and VueJS all over our core sites; these client-side applications are minified and bundled, and subsequently bootstrapped or loaded up on a plain old HTML page served by some routing layer, created by your favourite template language of choice.

Now here comes the fun part.

Whilst one might expect to have to deploy whichever app is serving up the route that renders the client side app, THE OUTNET doesn’t.

Instead, THE OUTNET Tech team has adopted an approach based on uploading the bundled file to an S3 bucket (or file storage of your choosing), and changing a value in a centralised database to match the new bundled filename. The routing app knows to look in the bucket for a hash value (corresponding to the bundled file name — taken from the database value) to render appropriately.

This, coupled with an admin panel that we already have, and which allows us to alter these database values easily, means we can change the values on the fly and rollback or update to different versions of these apps at will. The persistent nature of a file bucket means we can effectively use it for versioning also!

Rollbacks no longer require a deployment, we simply have to alter a value in a database (and wait for the routing app’s cache to expire) and – bingo! – we’ve updated our client-facing app.

Example Flows

Writing a new feature

Write the feature, get it into your master branch and let your continuous integration pipeline create the bundle and push it up to S3. From there, all that needs to be done is changing a value in the database. The routing app will read that file when its cache has cleared, and the job’s finished.

Rolling back to older version

Rolling back is even easier; just find the file reference and change the database value – all previous versions persist in S3, but even if it wasn’t there, just build and push the file again.

It’s a simple approach that may well have been adopted elsewhere, but so far, we haven’t seen much of it.

Have you?

Print Friendly

Leave a Reply