aaron stacy – frontend engineer – waterfall mobile



aaron stacy – frontend engineer – waterfall mobile

0 4


shipit

don't just build, ship

On Github aaronj1335 / shipit

aaron stacy

frontend engineer

waterfall mobile

@aaronj1335

- 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

github.com/aaronj1335/shipit

- 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

questions?

github.com/aaronj1335/shipit

thanks!