Your browser doesn't support the features required by impress.js, so the best I can do is a linear version of this Guide.

If you can, check it out using a modern desktop browser.

Press i at any point to get more information / helpful links.

Front End Ops


This talk isn't about grunt, bower or yeoman, it focuses more on the concepts and theory behind devOps and specifically how it can relate to the Front End.

There is this Catch 22 situation around a lot of these topics: where it’s very hard to actually learn them without being exposed to them (usually in large organisations) - and equally difficuly to get the role where you would be exposed to them, without the skills.

Importantly for me, the operational side of your application is still part of the product. If we want to build the best product we can, we need to be responsible for putting our own code into production and understand how it runs there.

No more throwing code over the wall.

Front end developers are probably the worst culprits of throwing code over the wall. The mentality of, “I pushed it, now it’s an Ops problem” is becoming a dated paradigm, one which has so many drawbacks.

As front end developers we should be levelling up and taking ownership of our code working correctly locally and in production, as well as understanding all the variables that sit between our code and the user.

Plus you don’t have to wait around for the ops guy any more… ;)

Key Concepts

“The metric by which a front-end operations engineer would be judged is speed.” - Alex Sexton, Smashing Magazine
  • Release (the best) code as fast as possible.
  • Begin the User Experience as fast as possible.
  • Enable fast feedback.

I'd never heard the term 'Front End Ops' before the Alex Sexton article. To me it was still DevOps but it was saying, "Step up, this is no longer just the work of back end devs." As it shouldn't be, we should always be looking to learn new skills which will help us become better developers.

By enabling the three quick processes and constantly finding ways to reduce the latency of the feeback loop, we are creating a better product.

And it’s not complicated to understand. There are two key principles which will work together to create a successful product lifecycle:

  • Offload as much as possibe
  • Tighten the feedback loop


Fast and Safe
Code Delivery

Fast User Experience

Safe Code Delivery

  • Create systems to protect the production environment.
  • Offload risk away from any individual developer.
  • Give feedback as early as possible.

We need to enable quick and early feedback for each developer in order to ultimately make their code better. Having your files watched by JSHint is an example of immediate feedback, but with longer proesses we need to create more structured gateposts.

The real challenge here is to get developer investment in the process. Each developer is protective of their development environment and by integrating this process you are introducing unknows. You need to invest time to maintain the checks and keep them fast otherwise developers will find a way to bypass them.

We need to manage the relationship between speed & risk:

  • Changing code on the server - fast but risky-as-hell.
  • Synthetic performance testing - slow but safe.

Save & Pre-Commit

Our first opportunities to run small, fast, composable tasks:

  • Remove trailing whitespace.
  • Ensure styleguide compliance.
  • Remove debuggers, local dependency references etc.


An opportunity to run slightly longer tasks:

  • Unit tests.
  • Visual Regression tests.
  • Code coverage, quality and complexity analysis.

In an ideal world we would run these tasks sooner, as the errors discovered at this point have already been committed. Unfortunately, anything longer than a couple of seconds will get in the way of developers at a commit level.

Errors discovered here can still be fixed and removed by rebasing.

Visual Regression

Code Complexity, Quality and Coverage

Code Review

Our last opportunity to sanity check before merging.

  • Thoroughness is more important here than speed.
  • An opportunity to share knowledge.
  • Not a personal critique.

Code Review

Ideally this should happen organically throughout the coding of the feature rather than simply being reviewed at this point.

If we catch entire implementation flaws at this point we have wasted time. Solutions should be discussed with peers early so that this step can simply be a human check to ensure we aren't committing anything sloppy or accidental.


Continuous Integration

CI can seem complex but is actually very simple:

  • A near-production environment in a centralised location.
  • A hook to trigger tasks.
  • A series of task runners that return 0 or 1.

Integration needs to be fast! In a large organisation this is a congested environment and usually the biggest bottleneck in releasing code.

Maintaining the CI environment requires a decent amount of care - speeding up tests, removing redundant tests, maintaining dependencies and keeping it in line with a production environment.

If you can, use a code-as-infrastructure tool like Chef or Puppet to maintain CI in line with production.



Moving files to a production environment in a consistent and automated manner.

  • Continuous Deployment, Delivery or Experimentation…?
  • Triggered on a successful Continuous Integration result.
  • Choose your deployment method & strategy.
  • Execute downstream jobs.

Deployment can be as complicated as you want it to be. It's just about moving code to a different environment. There are products like beanstalk which can get you up and running quickly and integrates well.

We package and deploy our application using Capistrano. We push all our assets to S3 and then cache them at the edge using Fastly.


A great round up of deployment strategies from Chris Coyier


Enabling a fast UX

You should know:

  • What lies on the critical path to the User Experience.
  • Which parts of the application to optimise.
  • How to protect the application.

You should have an understanding of the full stack, but that doesn't mean you need to be an expert at all of it.

If you have this high level understanding it gives you the ability to pick out which parts are the bottlenecks, weak points for your particular application.

Application Level

  • Where’s our origin server?
  • What can we cache at this tier?
  • What can we monitor?

Up until 2 years ago we operated out of Australia. Not the best place for latency. Go where your users are.


Load Balancer or Proxy

Not always necessary, but an opportunity to:

  • Protect your application.
  • Split traffic.
  • Monitor latency.

By protecting your application we talk about blocking ddos attacks, bots etc. It's important to cut this off before your application. A broken app is the slowest kind.

If we split traffic we can run server side AB tests, carry out rolling deploys, split our application into small parts etc.

Load balancer latency is a good metric to alert on because it cuts out some of the variability of the network layer.



Work out what you can cache.

  • The entire page.
  • Static Assets.
  • The DNS lookup.

Uh oh, now everything is cached…

  • Cookies, Authentication, Localisation.
  • Expose what is cached, and where, to the team.
  • Have cache busting mechanisms.

How static is your site? Are there whole pages you can store at the edge?

Be aware that caching something away from your application creates new headaches.



Minimise the critical path:

  • Uniquely identify your assets e.g. application-e8f29d9.css
  • Tweak asset config to increase cache hit rate.
  • Serve everything from the edge.

And kick off client-side monitoring:

  • RUM Timings.
  • Javascript Errors.
  • Custom user events.



Collect Metrics

  • How do you know what to measure?
  • Collect using tools like statsD, Logstash or even a 1x1.
  • Expose them to your team.
  • Figure out what they mean.

Knowing what to measure is really hard, and very specific to your own product/application. What you measure will evolve as your app evolves.

Find creative ways of exposing them to your team.


Use the Feedback

  • To decide on the next features/bug-fixes.
  • To improve your feedback loop.
  • To remove HIPPOs* from the equation.
  • Tom make the product better.

* Highest paid person's opinion


Any questions?

Or ask away on twitter - @ianfeather