aaron stacy
frontend engineer
- good afternoon
- aaron stacy
- frontend dev @ waterfall
- work on webapps that make sms marketing campaigns
- most of my time on the frontend
- big single-page app
- that's my handle on twitter and github
- slides posted on github
- they actually serve as an example for this talk
- you'll see examples and links throughout
- you can go there to see all of this in action
- dymaxion house
- from inventor bucky fuller
- original in 1929, redesigned in 1945
- design for a house that's interesting for a number of reasons
- first, it had groundbreaking ideas for sustainability
- cause he really prioritized lower water and energy usage
- that was before a lot of people were thinking about it
- second, was intended to repurpose factories that made fighter planes in WWII
- third and most importantly, people thought it looked cool
- successfully prototyped, orders placed for mass production
- but i bet you've never seen one of these around town
- that's because bucky never shipped this to production
- a lot of us identify with how hard that is
- we LOVE to build, invent, create
but we need to ship
- but we have a hard time shipping
- this is what i want to talk about today
- tools that help your project
- evolve
- accept pull requests
- push fixes and features
we've got a lot of tools
that help us build
- browsers' dev tools
- module loaders
- css preprocessors
- how many mvc frameworks??!
- like bucky we've got a lot of great tools
- he benefitted from advancements that came out of the war
- we benefit from advancements that come out of the browser wars
- the browser dev tools stuff you hear about from paul irish
- all the cool stuff the team at mozilla is shipping in their dev tools
- module loaders
- css preprocessors
- how many mvc frameworks?!
- how many of you use grunt?
- but even with all of this there are still barriers to shipping
- and you folks have seen all of this stuff
- say you're submitting a pull request to a project for the first time
- or you just started a new job
the mysterious "tests" folder
- there's a mysterious "tests" folder
- test.html, test_one_thing.js, test_another.js
- open it up, no dice (doesn't load successfully or there are failing tests)
- check commit logs, last commit 2 decades ago
- SO, at one point somebody did the right thing
- BUT it never became a regular thing, never integrated into the process
- now you don't know if you're going to break something
- that's a barrier to shipping
n00bs
- managing n00bs
- but say you get your project under control
- you're writing tests for bug fixes
- and then you hire junior developer
- and their first commit introduces a regression
- and the tests do their job and fail
- but that n00b just didn't bother to run them
- (thing is, if you're like me, a lot of times that n00b is you)
- those regressions are a barrier to shipping
- when it comes to releasing
- a lot of organizations have a lot of tribal knowledge
- you ask what the release process is
- and the answer is something like
- "you go to devops bill"
- "and he's the one with the password to the ftp server"
- "so you give him a tarball"
- etc
- two problems:
- we all suffer from fat fingers sometimes
- and this could really screw stuff up
- the other problem is something we call the bus factor
- if bill was to walk out in front of a bus tommorow
- how difficult would it be for your team to move forward
- and this keeps us from shipping
continuous integration
- the path forward here is something called continuous integration
those things you do
when you release
- run tests
- minify
- concatenate
- compile
- deploy
except all the time,
every commit
- this is a good thing!
- this helps us ship
- we're not waiting until the last minute to do this stuff
- so it actually happens
- the barrier to entry
- the breadth of stuff out there on continuous integration
- writings:
- martin fowler
- software
- jenkins server
- teamcity server
- services
- travis-ci
- circle-ci
- shining panda
- cloudbees
- this can be overwhelming
- this can be a real roadblock
- and you've already got your workflow
- you've probably invested a lot of time in it
- that's where you're most effective
- so you don't want to have to change it
- the thing is you don't need to know all of this stuff
- if you just choose something
- and then you can make it better over time
- so let's go through a quick example
- let's take a project that's using grunt
- set up continuous integration with travis
- i'm sure there are a lot of services out there
- i've had good experiences w/ travis b/c
- tight github integration
- always available on irc
we want to:
- run our tests on every commit
- receive an e-mail when something breaks
-
not receive an e-mail when stuff doesn't break
- know if merging a pull request will cause problems
- start with some goals
make grunt test work
- this is a task you define or already have defined
- it runs all of your tests, unit, integration
- lots of stuff for this:
- grunt-contrib-qunit
- grunt plugins for mocha
- if you need a browser environment, grunt plugins for phantomjs
- if you need a cross-browser tesging, grunt plugins for saucelabs and
browser stack
add a .travis.yml to your repo:
language: node_js
node_js: ["0.10"]
before_script: npm install -g grunt-cli
script: grunt test
[docs]
[example]
- if you're reading this, you'll notice the first line
- language says node, but could be any environment (browser, node)
- if it is node, specify multiple versions
- the rest is kind of just boiler plate
- links to docs and example
- this will run our tests on every commit
we want to:
- run our tests on every commit
- receive an e-mail when something breaks
-
not receive an e-mail when stuff doesn't break
- know if merging a pull request will cause problems
- that's our first goal
- and if the build fails...
- we get an email notification
- we can click that top link...
- and we can inspect the full log to see what happened
we want to:
- run our tests on every commit
- receive an e-mail when something breaks
-
not receive an e-mail when stuff doesn't break
- know if merging a pull request will cause problems
- so there's our second goal
- now once we push a fix...
- one email telling us everything is cool
- and then nothing after that until things are broken again
we want to:
- run our tests on every commit
- receive an e-mail when something breaks
-
not receive an e-mail when stuff doesn't break
- know if merging a pull request will cause problems
- that's our third goal, minimize the noise
- last goal was some indication that merging a pull request would break things
- so if we've got some troll that converts everything to coffee script
- and breaks all of the unit tests
- we can see it before doing anything
- so that's our four goals:
- run tests every commit
- e-mail when things break
- minimal noise
- warning if merging a pull request will cause problems
- so that's cool and all
- it's kinda scary how much our boy travis knows
- he knows:
- when we commit
- when that commit breaks stuff
- and when it doesn't
- he knows when other people try to commit
- that's a lot
- seems like he's holding out on us
- wouldn't it be nice if he could just go ahead and deploy for us too?
- of course, he can
- let's look at an example of deploying on successful builds
we want to:
- deploy our app on a successful build
- we've only got one goal this time
make grunt deploy work
- this could also be a lot of things
- especially since our project could range from a jquery plugin to a web app
- there are a handful of good services for deploying:
- heroku
- nodejitsu
- redhat openshift
- in all of these cases, deploying is as simple as `git push`
- this is a really good way of doing things
- in terms of software engineering,
- a lot of good ways to authenticate this that are secure, relatively convenient
- it gives us a known state of our system
- we know how to roll-back
- i'm hosting these slides on github pages
- "deploying" means copying some files to a local branch
- so you should check out the repo
- you can find a little 15 line example grunt task of how i did this
- side note:
- more often than not you don't want to go to production every commit
- but you probably want to push good changes to a staging server
- or maybe it's a little jquery plugin
update your .travis.yml:
language: node_js
node_js: ["0.10"]
before_script: npm install -g grunt-cli
script: grunt test
[instructions]
[example]
update your .travis.yml:
language: node_js
node_js: ["0.10"]
before_script: npm install -g grunt-cli
script: grunt test
# additional info for automatic deployment
after_success: grunt deploy
env:
global:
- secure: GvrIQCbjeEB... # generated token
[instructions]
[example]
- you can see our grunt deploy command
- then some security stuff
- that can be tricky and a bit scary, so let's talk about that
- that token is a special password from github
- it can be used to push to your repos
- but you can revoke it at any time
- if you change ci services or something gets hacked
- but we don't want commit it in plain text to the repo
- then we encrypt it using a service from travis
- and then the only people that can read it are travs (and the nsa)
- but this achieves our goal
- with relatively little effort
- in short amount of time
- we've set up some powerful tools
- that let us know when something breaks our project
- and act as a gatekeeper and automatically deploy good changes
- and that's going to help us ship
busy people ❤ this
teams ❤ this
everybody #winning
- busy people love this because it's so efficient
- it makes you more productive
- teams love this, whether you're:
- developer and you don't want to look bad because your stuff breaks
- qa or tester and you want to maintain a high level of quality
- project manager and you want to ship on schedule
- everybody wins
- and if you implement something like this it gives you the chance to be the
hero
- i hope i'm not the only one who looks at that picture and sees a hero
- anyway that's everything i wanted to go over
- we've got a little bit of time
