On Github rupl / frontend-ops
Or: How to Automate the Process of Breaking Things
frontend dev @ Four Kitchens
I contribute to open source stuff:
None: if you're familiar with DevOps, this is not new.
However, since frontend is a different game than backend, its operational needs are slightly different.
Often, a PHP error results in a 500 or blank page. You either get HTML or not.
(or you can at least use XHProf)
There are untold number of subtle errors that can occur on the frontend.
Additionally, frontend development is becoming more critical as the trade matures.
We need the same workflow tools that the backend has had for years.
Alex Sexton wrote an article for Smashing Mag describing the ideal frontend ops engineer.
Most people are using Drupal to build websites instead of webapps, so this presentation will cover useful tasks for website development.
In order to deliver the best, fastest site possible, we have to change our development processes.
Performance is not a checklist, it's acontinuous process. — Ilya Grigorik …don’t take measures without measuring them. — Maximiliano FirtmanThe slides AND code are on GitHub, I will tweet the link, and it's already available on the session page of the DrupalCon site. Yes, you may take code from the slides and use it for any purpose :)
This presentation is using a fresh clone of these slides, using the many examples I provided in the repo.
We all have to do repetitive tasks. Let's take the pain out of the process and focus on our actual work.
Automation helps us stay consistent.
Grunt is a "JavaScript task runner"
It does grunt work for you.
Grunt has a thriving community that offers plugins just like Drupal modules.
They have excellent intro instructions, and these slides contain several examples too.
Headless instance of WebKit
Phantom does everything a webkit browser can do, except there's no monitor. It CAN produce visual pages on command.
It's an indispensible tool for automating tasks that require loading up a web page and doing something (screenshots, window resizes, clicking things, etc)
(not yet) headless instance of Gecko
SlimerJS is a newer project than Phantom, but it aims to offer the same features to Firefox browser/OS users.
The meat 'n' potatoes of frontend.
JSHint is a code quality tool. It can help you debug JS and catch any little mistakes you might make.
It can also do lots of nice things like tell you when you have unused variables.
However, the web UI can be a pain to use, with lots of copy/paste involved. It's much nicer to run JSHint automatically after every file save.
# examples/grunt/jshint $ npm install # usage $ grunt watch # show all errors without stopping $ grunt watch --force
Then just save your files like normal :)
Check out the DrupalCamp Austin repo that includes a pretty comprehensive gruntfile with some docs.
YSlow is a service that grades frontend performance based on many tried and true facets. Developed at Yahoo! when they were the kings of perf.
It delivers A-F on the various tests, but historically required the user to visit each page in a browser.
# capture a HAR file from the CLI $ phantomjs examples/netsniff.js http://example.com/ > ex.har # install/run YSlow on the waterfall (node.js) $ npm install yslow -g $ yslow --info basic --format plain ex.har # Full grade report of FK website, all in one line $ phantomjs examples/netsniff.js http://fourkitchens.com | yslow --info grade --format plainOriginal code compliments of Ilya Grigorik YSlow also has a phantomjs package
Not to be outdone by Yahoo, Google has a competing service called PageSpeed Insights.
It can also be automated, by getting an API key. Or signing up for PageSpeed service.
PageSpeed API is documented quite thoroughly, but there's also a grunt plugin.
# examples/grunt/pagespeed $ npm install $ grunt # runs default task $ grunt pagespeed:mobile # runs mobile taskView code on GitHub
Phantomas is a PhantomJS-based web performance metrics tool
It gives you loads of data about how the frontend of your website is performing.
The usage guide is extensive.
# install via npm $ npm install -g phantomas # run a basic report $ phantomas --url http://example.com # set viewport dimensions, generate images of rendering process $ phantomas --url http://example.com --viewport=320x480 --film-strip # assert a test for total number of requests $ phantomas --url http://example.com --assert-requests=20
The grunt plugin is not just a wrapper for running the tool.
It makes reporting trends easier with charts that update each time you run the grunt task
# examples/grunt/phantomas $ npm install # run report $ grunt phantomas:default # run report and generate screenshot $ grunt phantomas:screenshot # test for certain values. this might cause failure! $ grunt phantomas:requestsView code on GitHub
CSS regressions? say it ain't so!
Having no scope at all, CSS is the easiest thing to nudge out of place. It's easier to prevent than you think.
Wraith uses either Phantom or Slimer (your choice) to take screenshots of two environments, producing a visual diff of the two screenshots!
# examples/wraith $ ./install.sh $ cd wraith $ rake # runs their example against bbc.co.uk $ open shots/gallery.html # view results in the browser
Wraith handles one comparison per config file.
However, it has support for multiple configs, so several config files in one repo allows for multiple comparisons.
$ cd /path/to/wraith/configs $ rake config[homepage] $ rake config[dashboard]
Prerender is relatively new, and lets you pre-load whole pages before a user clicks.
Since it's a heavy-handed but super-useful optimization, you MUST make sure it is only used in situations where it's absolutely appropriate.
Google Analytics — Audience » Visitors Flow
# examples/prerender $ ruby report.rb login@gmail.com password UA-XXXXXX-YOriginal code compliments of Ilya Grigorik
Testing in loads of browsers is a necessary but tedious task.
Services like BrowserStack.com make testing much simpler.
Everything outlined in this section requires two key ingredients:
Four Kitchens uses Jenkins and GitHub WebHooks in our workflow, and you can use whatever you wish.
An oldie but goodie: check out our how-to from 2011
You push to GitHub master branch (or merge PR) GitHub sends a message to your CI server "Yo Jenkins, the repository was updated!" CI server pulls the new code to your staging areaAlthough fairly mundane in terms of CI, the blog post illustrates the basic concepts underlying all of the tasks involving Jenkins.
Contact me:
chris ❀ fourkitchens.com